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Volume  1  consists  of  the  Executive  Summary  and  Sections  I  through  VII 
of  the  report  as  shown  on  the  Table  of  Contents  that  follows.  Volume 
2  consists  of  Section  VIII,  the  References  and  Appendices. 
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EXECUTIVE  SUMMARY 


EXECUTIVE  SUMMARY 


This  document  is  the  final  report  of  Contract  MDA-903-81-C-06I5 , 
"Develop  a  Recommended  System  Design  for  an  Occupational  Health 
Management  Information  System,"  sponsored  by  the  U.  S.  Department  of 
the  Army  (DA),  Office  of  the  Surgeon  General,  Health  Services  Command. 
This  report  provides: 

o  A  recommended  system  design  for  the  Department  of  the  Army's 
Occupational  Health  Management  Information  System  (hereafter 
referred  to  as  OHMIS).  The  system  design  includes: 

Detailed  Functional  Data  Flows  for  each  of  the  core 
data  processing  functions  of  OHMIS.  These  are  in  the 
form  of  Input/Processing/Output  algorithms  (IPOs)  and 
are  in  sufficient  detail  to  enable  the  core  computer 
programs  that  make  up  OHMIS  to  be  developed  directly 
from  the  Functional  Data  Flows. 

Detailed  descriptions  of  the  inputs  and  outputs  of  the 
OHMIS  core  data  processing  functions. 

Descriptions  of  the  p erfornance  specifications  of 
OHMIS. 

An  overview  of  the  resources  required  to  develop  and 
operate  OHMIS  and  the  expected  impact  of  OHMIS.  (Given 
in  Volume  II. ) 

o  A  summary  of  the  rationale  for  the  recommended  system  design 
for  OHMIS. 

o  A  description  of  the  methodology  used  to  develop  the 
recommended  system  design  for  OHMIS,  including: 

The  methods  used  to  identify  the  DA  informational  needs 
that  should  be  served  by  OHMIS.  The  major  methods  used 
were: 

1)  a  review  of  the  occupational  safety  and  health  and 
automated  data  management  regul atory 
requirements  to  identify  those  requirements  that 
should  be  met  by  OHMIS;  and, 

2)  interviews  with  all  of  the  potential  users  of 
OHMIS  to  establish  their  informational  needs.  The 
interviews  included  visits  to  five  DA 
installations  to  examine  local  installation 
informational  needs. 

The  informational  needs  were  surmiarized  in  the  forms  of 
"use  modules"  listing,  for  each  major  user  of  OHMIS, 
the  ways  in  which  the  user  could  be  expected  to  use 
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OHMIS  to  perform  his/her  occupational  health  program 
functions.  These  use  modules  form  the  basis  of  the 
recommended  system  design  for  OHMIS. 

The  methods  used  to  evaluate  the  two  major  options  for 
developing  a  recommended  system  design  for  OHMIS  and 
select  one  of  the  options.  The  two  options  were: 

1)  select  an  existing  occupational  health  information 
system  and  adapt  it  for  use  as  OHMIS;  or 

2)  develop  a  new  system  for  OHMIS. 

A  review  of  the  existing  commercial  systems  using  a 
specified  set  of  evaluation  criteria  was  made.  These 
systems  were  compared  with  each  other  and  a  hypothe¬ 
tical  new  information  system  to  determine  which  of  the 
two  options  would  yield  the  best  system  for  the  Depart¬ 
ment  of  the  Army.  The  conclusion  reached  was  that  the 
development  of  a  new  system  was  the  best  option.  This 
conclusion  was  reached  primarily  because:  1)  the 
development  of  a  new  system  means  that  the  system  can 
be  designed  specifically  to  meet  the  Department  of  the 
Army's  informational  needs;  and  2)  the  projected  costs 
for  developing  a  new  system  were  under  the  budgeted 
amount  for  the  development  of  OHMIS. 

SUMMARY  OF  THE  RECOMMENDED  SYSTEM  DESIGN  FOR  OHMIS 


A  sumnary  of  the  features  and  the  two  primary  data  processing 
functions  of  the  recommended  system  design  for  OHMIS  is  given  below. 

Features  of  the  OHMIS  Recommended  System  Design 

The  recommended  system  design  for  OHMIS  described  in  this  report  has 
the  following  major  features: 

o  The  costs  of  OHMIS  are  within  the  constraints  of  the  Class 
IV  system,  i.e.,  less  than  $3  million. 

o  OHMIS  will  use  five  major  types  of  data.  These  are: 

1.  Data  on  the  characteristics  of  the  DA  employees  (both 
military  and  civilian)  covered  by  OHMIS; 

2.  Data  on  the  characteri sties  of  the  workplaces 
(facilities  and  sites)  covered  by  OHMIS; 

3.  Data  on  the  hazards  to  which  DA  employees  are  exposed; 
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4.  Data  on  medical  events,  i.e.,  information  on  the 
injuries  and  illnesses  incurred  by  DA  employees  and  the 
medical  services  received  to  prevent  or  treat  the 
injuries/il’nesses;  and 

5.  Data  on  the  preventive/corrective  actions  addressing 
the  hazards  to  which  DA  employees  are  exposed  or 
ameliorating  the  injuries/illnesses  incurred  as  a 
result  of  exposure  to  these  hazards.  This  type  of  data 
includes  requirements  description  data,  i.e.,  data  on 
the  policies  and  procedures  that  the  DA  prescribes  for 
the  operation  of  its  occupational  health  program.  A 
major  source  for  such  preventive/corrective  actions  and 
requirements  data  is  occupational  safety  and  health 
regulations. 

To  the  greatest  extent  possible,  OHMIS  will  use  the 
existing  DA  data  sources  for  the  above  five  types  of  data. 
Significant  portions  of  the  largest  types  of  data  used  in 
OHMIS  are  already  available  in  computerized  form  on  DA  data 
bases  developed  for  other  purposes.  In  particular,  the 
majority  of  the  first  two  types  of  data  used  in  OHMIS 
(employee  and  workplace  characteristics)  is  available  on  the 
DA's  existing  personnel  and  facilities  information  systems. 

A  significant  source  for  the  third  type  of  data  (hazards 
data)  is  the  DA  supplied  information  systems;  and,  some  of 
the  fourth  type  of  data  (medical  events  data),  particularly 
for  impatient  medical  services,  is  available  on  computerized 
DA  data  bases.  These  data  sources,  developed  by  DA  agencies 
other  than  the  Occupational  Health  Program  activity,  are 
referred  to  as  "external  data  sources."  To  make  the  system 
economical,  OHMIS  will  not  regenerate  the  data  in  these 
external  data  sources.  Instead,  copies  will  be  routinely 
made  of  the  data  elements  relevant  to  OHMIS  that  are  on  the 
existing  data  bases  of  the  external  sources.  Supplements  to 
these  data  sources  will  be  made  through  input  of  data  unique 
to  OHMIS.  Only  the  fifth  data  type  (preventive/corrective 
actions  and  requirements  description  data)  will  be  almost 
entirely  generated  by  the  operation  of  OHMIS.  Throughout 
the  design  of  OHMIS,  the  distinction  is  made  between  data 
generated  from  external  data  sources  and  data  generated 
solely  by  OHMIS.  Almost  all  OHMIS  generated  data  is 
expected  to  be  entered  onto  the  OHMIS  data  base  through  data 
entry  forms  developed  specifically  for  OHMIS.  The  descrip¬ 
tion  of  the  core  data  processing  functions  of  the  recommen¬ 
ded  system  design  for  OHMIS  is  confined  to  OHMIS  generated 
data. 

OHMIS  is  expected  to  use  VIABLE  as  the  host  hardware  for 
the  system.  VIABLE  is  a  hardware  and  executive  software 
environment  currently  in  the  installation  phase  in  47  DA 
bases.  It  will  be  the  primary  base-operated  information 
systems'  capability  for  most  DA  installations.  As  a 


possible  host  for  OHMIS,  such  a  network  seems  ideal, 
because: 

The  easily  expanded  on-line  storage  capacities  are  well 
suited  for  a  system  of  the  size  of  OHMIS; 

Using  VIABLE  as  a  host  significantly  lessens  the 
hardware  procurement  burden  (costs  and  delays  in 
implementation)  which  would  otherwise  be  necessary; 

Many  of  the  external  DA  data  sources  with  which  OHMIS 
must  interface  will  also  use  VIABLE  as  their  host 
environment;  therefore,  interface  with  these  external 
data  sources. 

o  OHMIS  is  designed  to  allow  interactive,  on-line  entry  of 
OHMIS  generated  data  and  interactive,  on-line  query  of  all 
OHMIS  data.  One  of  the  most  frequent  complaints  about 
current  DA  occupational  health  data  expressed  by  the  poten¬ 
tial  users  of  OHMIS  is  that  the  data  is  not  readily  availa¬ 
ble  to  them.  Another  problem  noted  is  the  very  poor  quality 
control  of  existing  DA  data  bases  that  do  not  allow  for 
interactive  entry  and  editing.  The  interactive  feature  of 
OHMIS  is  designed  to  address  these  problems.  A  Data  Base 
Management  System  (DBMS)  approach  will  be  used  in  the  design 
of  the  query  system  for  OHMIS.  The  majority  of  the  outputs 
of  OHMIS  will  be  generated  using  this  DBMS  query  system. 

This  means  that  the  outputs  of  OHMIS  will  vary  according  to 
the  individual  users'  changing  needs.  For  this  reason,  only 
the  information  system  management  outputs  and  the  outputs 
automatically  generated  by  OHMIS  as  a  part  of  its  core 
data  processing  functions  are  described  in  the  recommended 
system  design  given  in  this  report. 

o  OHMIS  has  been  designed  to  be  highly  flexible  and  readily 
adaptable  to  change.  The  reason  for  this  feature  is  that 
it  is  expected  that: 

The  informational  needs  of  the  Department  of  the  Army’s 
occupational  health  program  will  change  over  time; 

There  will  be  significant  and  frequent  changes  in  the 
requirements,  including  regulations,  under  which  the  DA 
occupational  health  program  will  operate; 

The  external  data  sources  on  which  OHMIS  depends  for  a 
large  supply  of  its  data  may  change; 

Agencies  external  to  the  DA,  such  as  the  TRIMIS  (Tri- 
Service  Medical  Information  Systems)  project,  which 
prescribe  specifications  for  the  medical  information 
systems  of  the  Department  of  Defense  (DoD),  will 
continue  to  prescribe  information  systems  specif ica- 
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tions  affecting  OHMIS  and  resulting  in  the  need  to 
change  OHMIS  to  comply  with  these  specifications;  and. 

There  will  be  considerable  variation  between  local 
installations  in  the  needs  for  and  uses  of  OHMIS. 


Some  of  the  features  of  the  recommended  system  design  for 
OHMIS  that  make  it  readily  adaptable  to  change  are: 

All  OHMIS  generated  data  may  be  entered  using  one 
common  data  entry  program,  namely,  a  program  for  enter¬ 
ing  data  from  specially  designed  data  entry  sheets 
(referred  to  generically  as  OHMIS  forms); 

Users  may  develop  new  OHMIS  forms  at  any  time  without 
additional  programming  and  without  changing  or  degrad¬ 
ing  the  current  OHMIS  data  base; 

A  generic  method  for  entering  and  processing  the 
requirements  data  that  will  initiate  the  operation  of 
OHMIS  and  prescribe  the  management  functions  performed 
by  OHMIS  has  been  developed.  This  generic  method 
allows  frequent  and  extensive  changes  to  these  require¬ 
ments  without  affecting  the  current  OHMIS  data  base  or 
requiring  changes  in  the  OHMIS  computer  programs. 


OHMIS  is  designed  to  automatical ly  perform  the  two  primary 
data  processing  functions  of  any  occupational  health 
program,  namely: 

The  requirements  triggering  function.  OHMIS  allows 
the  user  to  specify  requirements  and  preventive/ 
corrective  actions  for  the  operation  of  the  DA  occupa¬ 
tional  health  program.  OHMIS  then  uses  these  specifi¬ 
cations  to  routinely  and  "automatical ly1'  identify 
the  occasions  or  circumstances  in  which  these  require¬ 
ments  apply,  i.e.,  to  "trigger"  the  execution  of  the 
required  actions. 


The  requirements  monitoring  function.  OHMIS  is 
designed  to  routinely  audit  the  DA  occupational  health 
program  activities  in  order  to  monitor  the  status  of 
all  applicable  required  actions  (and  all  data  entry 
forms  associated  with  executing  these  actions)  until 
these  actions  and  forms  are  completed. 


During  the  review  of  DA  occupational  health  informational 
needs  made  during  the  development  of  OHMIS,  it  was  found 
that  the  most  significant  need  is  for  an  information  system 
that  will  assure  that  all  applicable  policies  and  require¬ 
ments  for  the  DA  occupational  health  program  are  continually 
identified,  triggered  and  monitored  with  a  high  degree  of 
accuracy,  consistency  and  comprehensiveness.  These 
functions  are  currently  being  performed  manually  by  DA 


occupational  health  program  managers  and  personnel  to  a 
large  degree.  The  implementation  of  OHMIS  will  assure  that 
the  triggering  and  monitoring  of  occupational  health  program 
requirements  is  performed  more  systematically  and  consis¬ 
tently  and  that  changes  in  the  occupational  health  program 
requirements  are  readily  reflected  in  the  operation  of  the 
DA  occupational  health  program. 

The  institution  of  the  OHMIS  requirements  triggering  and 
monitoring  capabilities  will  mean  that  the  Department  of  the 
Army's  occupational  health  program  will  be  considerably  more 
powerful  and  useful  than  other  programs  using  existing  occu¬ 
pational  health  information  systems.  The  current  conven¬ 
tional  occupational  health  information  systems  do  little 
more  than  store  and  retrieve  requirements  data  or,  at  most, 
identify  abnormal  readings.  The  potential  for  using  the 
occupational  health  information  system  to  actually  perform 
the  management  functions  of  requirements  triggering  and 
monitoring  has  not  been  previously  recognized.  The  use  of 
an  occupational  health  information  system  in  this  was  is  a 
newly  conceived  feature  that  will  make  the  Army's  OHMIS 
system  unique. 

Two  Primary  Data  Processing  Functions  of  OHMIS 

FIGURES  1  and  2  show  how  the  two  primary  data  processing  functions  of 
an  occupational  health  program  (i.e.,  requirements  for  triggering  and 
monitoring)  are  performed  by  OHMIS  as  it  is  designed  in  the  recommen¬ 
ded  system  description  given  in  this  report.  FIGURE  1  provides  a 
description  of  the  types  of  data  needed  to  start  OHMIS,  i.e.,  data 
that  must  be  preloaded  before  OHMIS  becomes  operational.  The 
majority  of  the  preloaded  data  is  requirements  type  data.  FIGURE  2 
shows  the  data  entered  to  operate  OHMIS  and  the  core  data  processing 
functions  that  are  automatically  initiated  by  the  entry  of  any 
operational  (i.e.,  not  pre loaded)  data  into  the  OHMIS  data  base.  The 
operational  data  consists  of  all  of  the  five  major  types  of  OHMIS  data 
described  above,  except  the  requirements  type  of  preventive/corrective 
actions  data.  FIGURE  2  also  indicates  the  point  in  the  OHMIS  program 
at  which  the  preloaded  data  is  used  to  examine  the  operational  data 
and  perform  the  requirements  triggering  and  monitoring  functions, 
i.e.,  perform  the  management  decision-making  process  involved  in 
administering  an  occupational  health  program. 

As  can  be  seen  in  FIGURE  1,  there  are  four  types  of  preloaded  data. 

The  first  three  types  are  requirements  description  data;  the  fourth 
type  is  data  on  the  personnel  resources  available  for  scheduling  the 
required  occupational  health  program  actions.  Some  of  these  types 
of  data  must  be  entered  onto  the  OHMIS  data  base  prior  to  its  initial 
operation;  this  preloaded  data  can  be  added  to  or  changed  at  any  time. 

FIGURE  2  shows  how  each  of  the  preloaded  data  types  (Data  Types  A-D) 
identified  in  FIGURE  1  are  used  by  OHMIS  to  automatical ly  perform 
all  of  the  required  data  processing  functions  needed  for  the  two  core 
program  functions  involved  in  the  administration  of  the  DA  occupa- 
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tional  health  program,  namely,  the  triggering  and  monitoring  of 
requirements.  Specifically,  FIGURE  2  shows  that  each  time  there  is 
input  to  OHMIS,  either  in  the  form  of:  1)  "logging  onto"  the  OHMIS 
system,  2)  entering  data  from  an  external  data  source,  or  3)  entering 
data  from  an  OHMIS  form  (shown  by  the  three  parallelograms  on  the 
right  side  of  FIGURE  1),  OHMIS  will  automatically: 

1.  Execute  the  requirements  triggering  function,  i.e.,: 

Decide  whether  the  input  of  the  user  indicates  that 
there  may  be  some  potentially  applicable  requirements. 

Decide  what  requirements  should  be  triggered,  i.e., 
which  of  the  potentially  applicable  requirements  apply. 

2.  Execute  the  requirements  monitoring  function  (shown  in  the 
dotted  box) ,  i .e., : 

Schedule  the  tasks  (required  actions)  specified  by  the 
requirements  determined  to  be  applicable. 

Generate  the  OHMIS  forms  needed  to  conduct  the  required 
tasks  in  accordance  with  the  content  specifications 
of  the  applicable  requirements,  i.e.,  in  accordance 
with  the  specifications  for  the  exact  tests  and 
measurements  required  to  perform  the  required  tasks. 

Monitor  and  provide  status  reports  on  all  outstanding 
tasks  and  forms  until  they  are  completed. 

3.  Provide  a  means  for  entering  data  from  the  forms  completed 
during  the  execution  of  the  required  tasks.  The  entry  of 
OHMIS  forms  data  onto  the  OHMIS  data  base  sets  in  motion  a 
repeat  of  the  above  two  data  processing  functions.  That  is, 
the  OHMIS  program  determines  whether  the  data  from  an  OHMIS 
form  should  trigger  additional  requirements;  if  so,  which 
requirements;  etc. 

Both  of  these  primary  functions  can  be  performed  at  all  management 
levels  ranging  from  the  individual  local  installation  to  the  DA  or 
Command  level.  For  example,  in  the  monitoring  of  the  status  of  DA 
occupational  health  program  requirements,  the  OHMIS  program  will  allow 
the  DA  to  determine  the  status  of  the  implementation  of  any  particular 
type  of  requirement  (or  all  requirements)  at  any  given  installation  or 
command  or  all  installations/commands. 

REMAINING  PRE- IMPLEMENTATION  TASKS 


The  exact  data  processing  algorithms  through  which  the  primary  data 
processing  functions  are  performed  are  given  in  the  eleven  core  Func¬ 
tional  Data  Flows  shown  in  Section  6.8  of  this  report.  These  data 
flows  are  in  sufficient  detail  to  enable  the  corresponding  computer 
programs  to  be  developed.  Thus,  three  major  tasks  remain  before  the 
process  of  implementing  OHMIS  can  begin: 
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1.  Development  of  the  OHMIS  computer  programs  based  on  the 
Functional  Data  Flows  provided  in  this  report.  The  Func¬ 
tional  Data  Flows  give  the  Inputs/Processing/Outputs 
(I/P/Os)  algorithms  for  the  eleven  core  computer  programs 
needed  to  perform  all  of  the  primary  data  processing  func¬ 
tions  of  OHMIS.  Although  additional  programs  may  be  desired 
at  a  later  date,  no  additional  programming  is  required  to 
operate  OHMIS. 

2.  Development  of  the  initial  set  of  requirements  data  and 
resource  availability  data  that  is  to  be  preloaded  into  the 
OHMIS  data  base.  It  is  recommended  that  this  be  done  in  the 
format  of  a  DA  occupational  health  program  and  information 
system  procedural  manual.  The  review  of  DA  occupational 
health  program  documents  made  as  a  part  of  this  study 
revealed  that  much  of  the  information  required  to  preload 
OHMIS  is  already  available  in  written  form.  However,  there 
are  significant  gaps  in  the  occupational  health  program 
requirements  and  specifications,  at  present.  Some  of  these 
gaps  will  need  to  be  rectified  prior  to  completing  the  ini¬ 
tial  procedural  manual  for  OHMIS. 

In  most  cases,  the  content  specifications  of  the  occupa¬ 
tional  health  program  requirements  entered  into  the  OHMIS 
data  base  (e.g.,  the  exact  tests  or  measurements  that  should 
be  included  in  a  given  type  of  required  medical  examination 
or  a  given  type  of  Industrial  Hygiene  survey)  are  entered 
onto  the  OHMIS  data  base  by  specifying  the  contents  of  an 
OHMIS  data  entry  form  (i.e.,  by  specifying  the  data  ele¬ 
ments  that  are  to  be  collected  and  entered  onto  the  form). 
This  means  that  to  a  large  degree,  the  procedural  manual  • 
will  consist  of  a  series  of  OHMIS  forms.  Because  the  OHMIS 
core  data  processing  programs  use  one  standard  data  entry 
program  for  any  OHMIS  form,  it  will  not  be  necessary  to 
complete  the  initial  set  of  OHMIS  forms  before  the  develop¬ 
ment  of  the  OHMIS  computer  programs  can  be  started. 

3.  Finalization  of  the  procedures  for  interfacing  with  the  DA 
external  data  sources  and  using  the  VIABLE  system  as  the 
host  for  OHMIS.  The  feasibility  of  doing  both  of  these 
tasks  was  thoroughly  evaluated  during  this  project  and  found 
to  be  very  high.  However,  specific  procedures  are  needed. 

The  completion  of  these  three  tasks  will  enable  the  implementation  of 
OHMIS  to  begin.  With  the  institution  of  OHMIS,  the  Department  of  the 
Army  will  have  a  state-of-the-art  management  tool  needed  to  support 
the  decision-making  processes  involved  in  the  systematic  and  compre¬ 
hensive  operation  of  the  DA  occupational  health  program. 
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I .  BACKGROUND  AND  METHODOLOGY 


This  document  is  the  final  report  of  Contract  MDA-903-81-C-0515, 
"Develop  a  Recommended  System  Description  for  an  Occupational  Health 
Management  Information  System."  It  provides  a  recommended  system 
design  of  an  Occupational  Health  Management  Information  System 
(hereafter  referred  to  as  1  OHM I S ‘ )  developed  for  the  Department  of  the 
Army  (DA)  under  the  above  contract.  It  also  provides  a  description  of 
the  methodology  and  rationale  used  to  develop  this  recommended  system 
design  for  OHMIS. 

The  remaining  parts  of  Section  I  of  this  report  describe  the  back¬ 
ground  and  methodology  used  to  develop  the  OHMIS  recommended  system 
design.  Section  II  provides  a  review  of  the  features  and  capabilities 
needed  in  a  DA  OHMIS  system.  This  assessment  of  needs  is  based  on  a 
review  of  the  regulations  affecting  occupational  health  programs  and 
the  development  of  information  systems  and  interviews  with  the  poten¬ 
tial  users  of  the  DA  OHMIS  system.  Section  III  categorizes  the  users 
of  OHMIS  into  four  major  groups.  This  Section  also  summarizes  the 
needs  identified  in  Section  II  in  terms  of  how  each  of  the  major  users 
of  OHMIS  would  use  this  information  system  to  accomplish  their 
various  occupational  health  program  objectives.  These  potential  uses 
of  OHMIS  form  the  basis  of  the  recommended  system  design  for  OHMIS 
given  in  this  report.  Section  IV  explores  two  basic  options  for 
developing  an  OHMIS  for  the  Department  of  the  Army,  namely:  1)  using 
an  existing  commercially  available  system;  and  2)  developing  a  new 
system.  The  rationale  for  choosing  the  latter  option  is  also  given  in 
Section  IV.  Sections  V  through  VIII  provide  the  recommended  system 
design  for  OHMIS.  Part  I  of  this  recommended  system  design  (Section 
V)  provides  a  summary  of  the  recommended  system.  Part  II  (Section  VI) 
provides  the  detailed  program  logic  (referred  to  as  Functional  Data 
Flows)  for  each  of  the  11  core  data  processing  functions  of  the  recom¬ 
mended  OHMIS.  Part  III  (Section  VII)  provides  a  brief  description  of 
some  of  the  major  system  specifications  of  the  recommended  system. 

Part  4  (Section  VIII)  reviews  the  resources  and  impact  of  the  develop¬ 
ment  and  operation  of  OHMIS  as  envisioned  in  the  recommended  system 
design. 

1.1  BACKGROUND 


As  set  forth  in  the  Statement  of  Work  at  APPENDIX  A,  the  requirements 
of  Executive  Order  12196,  "Occupational  Safety  and  Health  Programs  for 
Federal  Employees,"  January  26,  198U,  as  implemented  within  the  Depart 
ment  of  Defense  by  Department  of  Defense  Instruction  (DODI)  6055.1, 
"Department  of  Defense  Occupational  Safety  and  Health  Program,"  and 
within  the  U.  S.  Army,  in  part,  by  Army  Regulation  (AR)  40-5,  "Health 
and  Environment,"  has  resulted  in  a  rapidly  expanding  requirement  to 
collect,  analyze  and  store  occupational  health  data.  Complicating 
this  growth  is  the  requirement  to  correlate  and  analyze  the  inter¬ 
actions  between  individuals  and  their  work  environment  and  to  store 
and  retrieve  the  results  of  these  analyses  for  as  long  as  25  years. 
Clearly  these  increased  data  handling  requirements  are  beyond  the  capa 
bilities  of  a  manual  information  system  except  at  the  smallest  Army 


installations.  Further,  the  need  to  centrally  manage  the  total  Army 
system,  involving  some  700  million  bytes  of  data,  virtually  dictates 
the  need  for  automation.  Accordingly,  Contract  MDA-903-81-C-0515  was 
awarded  (APPENDIX  A)  to  examine  Army  requirements  and  existing  systems 
and  to  prepare  a  plan  for  integrating  the  various  requirements  into  a 
cogent  whole.  The  result  of  this  effort  is  the  recommended  system 
design  for  the  Army  OHMIS  contained  in  this  report.  OHMIS  will 
establish  a  vehicle  to  permit  individual  Army  commands  and  installa¬ 
tions  to  operate  decentralized  occupational  health  programs,  while 
maintaining  control  of  program  criteria  and  oversight  functions  at  the 
Health  Services  Command. 

1.1.1  Other  Related  Projects  within  the  Department  of  the  Army 

This  Section  presents  background  information  on  the  current  or 
proposed  projects  within  DA  which  will  affect  and  which  will  be 
affected  by  the  implementation  of  a  comprehensive  OHMIS. 

o  VIABLE  (Vertical  Installation  Automation  Baseline). 

VIA8LE  is  a  hardware  and  executive  software  environment 
currently  in  the  installation  phase  at  47  DA  bases 
throughout  the  country.  The  well  thought  out  hardware 
conf iguration  establishes  a  network  of  distributed  and 
centralized  (regional  or  national)  processing  capabi 1 i ties 
and  the  ability  to  support  hundreds  of  local  users  in  an 
on-1 ine/interaction  environment. 

As  a  possible  host  for  a  proposed  OHMIS,  such  a  network 
seems  ideal.  The  easily  expanded  on-line  storage  capacities 
are  also  very  well  suited  for  an  information  system  of  the 
projected  size  of  the  proposed  OHMIS.  An  additional  benefit 
to  the  OHMIS  effort  in  using  VIABLE  as  a  host  is  the 
lessening  of  the  hardware  procurement  burden  which  would 
otherwise  be  necessary.  Perhaps  the  most  significant 
advantage  of  VIABLE  as  a  host  for  OHMIS  is  that  many  of  the 
existing  DA  data  bases  (e.g.,  personnel  systems  such  as 
SIDPERS,  facility  systems  such  as  IFS,  supply  systems  such 
as  SAILS,  etc.,  referred  to  throughout  this  report  as 
external  data  sources)  that  must  be  integrated  with 
OHMIS  for  OHMIS  to  operate  economically  will  already  be  on 
VIABLE,  thus  making  for  easy  "copying"  of  data  from  external 
data  sources. 

o  LOHHI  and  LQHHI  II  (Local  Occupational  Health  Hazard  Inven¬ 
tory)  .  This  system  sets  forth  a  catalogue  of  hazards  which 
affect  individual  Army  work  places.  The  system,  which  is 
updated  on  an  approximately  three-year  cycle,  includes  coded 
data  elements  for:  Command,  Subcommand,  Installation, 
Building  Number,  Room  Number,  Exposed  Workers  by  Name  and 
Civilian/Military  Breakout,  Operation,  Inventory  Date, 
Hazards  Present,  Controls  Required,  and  Status  of  Corrective 
Action.  As  presently  designed,  LOHHI  is  a  batch  processed 
system  with  no  capability  to  sort  and  compare  by  individual 
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data  elements.  It  is  proposed  to  incorporate  LOHHI  informa¬ 
tion  (expanded  and  reorganized)  into  the  OHMIS  with  the  goal 
of  a  data  base  that  can  be  incremental ly  updated  and  a 
system  of  outputs  that  are  useful  at  the  local  level. 

o  HEARS  (Hearing  Evaluation  Automated  Registry  System). 

This  system,  now  being  automated,  is  maintained  by  the  U.  S. 
Army  Environmental  Hygiene  Agency  (USAEHA)  to  monitor  the 
effectiveness  of  the  1).  S.  Army  Hearing  Conservation  Pro¬ 
gram.  DA  military  and  civilian  personnel  who  are  routinely 
exposed  to  hazardous  noise  are  required  to  receive  baseline 
and  periodic  (at  least  annual)  autometric  evaluations. 

Copies  of  the  Reference  Audiogram  (DD  Form  2215)  and  Hearing 
Conservation  Data  (DD  Form  2216)  are  sent  to  USAEHA  for 
entry  into  a  computerized  data  registry  via  a  key-to-disk 
process.  DD  Forms  2215  and  2216  have  been  evaluated  and  the 
proposed  OHMIS  will  have  the  capability  to  include  HEARS 
data  without  substantial  change.  An  additional  feature  of 
the  proposed  OHMIS  would  be  an  interactive  output  process 
(through  queries)  that  would  allow  the  user  to  easily 
retrieve  the  base  line  data  (Form  2215)  on  an  individual, 
when  preparing  new  periodic  data  (Form  2216).  The  data  from 
HEARS  will  also  be  integrated  into  OHMIS  so  that  OHMIS  will 
automatically  identify,  trigger  and  monitor  any  required 
actions  that  should  result  from  the  entry  of  a  particular 
value  for  a  HEARS  data  element  into  the  OHMIS  data  base 
(e.g.,  actions  required  to  follow-up  on  the  entry  of  a  value 
identified  as  being  abnormal). 

1.1.2  Other  Related  Projects  Outside  of  the  Department  of  the  Army 

In  this  Section,  projects  being  conducted  by  agencies  other  than  the 

Department  of  the  Army  that  are  related  to  OHMIS  are  briefly 

described. 

o  MSDS  (Material  Safety  Data  Sheet).  This  is  a  DoD  system 
that  is  operated  by  the  Defense  Logistics  Agency  and  is 
intended  to  "provide  technical  information  about  the 
hazardous  properties  of  items  that  in  some  manner  affect  DoD 
personnel  by  the  unique  aspects  associated  with  the  hazard¬ 
ous  items."  The  system  consists  of  a  data  base  of  the  chemi 
cals  and  related  properties  of  hazardous  substances;  this 
data  base  is  generated  by  entries  made  from  Material  Safety 
Data  Sheets  generated  by  individual  Industrial  Hygiene 
personnel  throughout  the  DoD,  who  are  actively  participating 
in  the  system.  The  system  suffers  to  a  degree  from 
duplication  of  effort  because  it  is  possible  for  more  than 
one  person  to  prepare  and  submit  a  Material  Safety  Data 
Sheet  for  the  same  hazardous  substance.  Because,  at 
present,  the  policy  of  the  DA  on  the  use  of  the  MSDS  system 
has  not  yet  been  formalized,  the  recommended  system  design 
for  OHMIS  assumes  only  that  OHMIS  users  may  use  the  MSDS 
microfiche  or  hard  copy  outputs  that  describe  the  hazardous 
properties  of  stock  listed  and  local  purpose  items.  However, 
the  OHMIS  system  has  been  designed  to  enable  integration  of 
OHMIS 
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generated  hazardous  substance  data  with  the  MSDS  system's 
data,  if  desired.  This  will  be  done  using  the  same  proce¬ 
dures  as  the  integration  of  OHMIS  with  other  external  data 
sources  such  as  the  OoD  personnel  systems,  facility  data 
systems,  and  supply  systems.  The  feasibility  of  achieving 
this  integration  between  the  OHMIS  and  the  MSDS  data  bases 
has  been  tentatively  established  as  a  part  of  the  interviews 
conducted  during  the  development  of  the  OHMIS  recommended 
system  design. 

o  TRIMIS  (Tri-Service  Medical  Information  Systems).  TRIMIS 
is  an  ongoing  project  to  develop  guidelines  and  procedures, 
as  well  as  specific  systems,  for  all  programs  and 
information  systems  throughout  the  Department  of  Defense, 
affecting  medical  information.  The  purpose  of  this  project 
is  to  avoid  duplication  in  and  easy  integration  of  the  great 
variety  of  information  systems  used  in  the  provision  of 
medical  services  by  the  DoD.  As  a  part  of  developing  the 
design  for  OHMIS,  interviews  were  held  with  persons 
responsible  for  interacting  with  TRIMIS  for  the  DA. 

Although  no  TRIMIS  projects  or  systems  currently  exist 
that  prescribe  the  characteristics  of  an  occupational 
heal th  information  system,  it  was  found  that  caution  must 
be  employed  in  the  design  of  any  new  system  to  allow  for 
integration  with  future  procedures  and  systems  developed 
under  the  auspices  of  TRIMIS.  Accordingly,  the  recommended 
system  design  for  OHMIS  proposed  in  this  report  has  features 
in  it  that  make  modifications  to  OHMIS  easy  to  execute,  so 
that  OHMIS  may  be  easily  adapted  to  comply  with  any  future 
data  processing  requirements  of  TRIMIS.  For  example,  in  the 
OHMIS  recommended  system  design  all  data  entry  forms  used  in 
the  system  can  be  readily  changed  without  any  additional 
programming  or  changes  in  the  OHMIS  data  base.  Therefore, 
should  TRIMIS  at  some  point  in  the  future,  prescribe  the 
content  of  a  particular  form  of  a  type  used  in  OHMIS  (such 
as  a  form  for  recording  information  about  the  medical 
services,  diagnoses  and  prognoses  for  outpatient  clinic 
visits),  the  then  current  OHMIS  form  can  readily  be  replaced 
by  the  TRIMIS  prescribed  form  at  that  time.  This  important 
design  feature  of  OHMIS  makes  it  possible  to  progress  with 
the  development  of  OHMIS,  rather  than  awaiting  requirements 
that  may  be  prescribed  by  TRIMIS  in  the  future,  but  still 
keep  the  design  of  OHMIS  in  accordance  with  TRIMIS 
specifications . 

o  UCA  (Uniform  Chart  of  Accounts).  This  is  a  system 

currently  being  developed  on  a  DoD-wide  basis  to  collect  and 
analyze  data  on  the  medical  services  performed  within  DoD. 
The  purpose  of  the  system  is  to  enable  resource  evaluation 
through  the  collection  of  data  on  the  number  of  services  of 
each  type  provided  and  on  the  resources  (people  and 
supplies)  used  to  provide  the  services.  Because  UCA  will 
eventually  be  used  in  all  DA  medical  facilities,  it  was 
felt,  at  the  beginning  of  the  project  that  UCA  may  become 
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a  potential  host  for  the  OHMIS  system.  Therefore, 
interviews  were  held  with  the  developers  of  UCA.  It  was 
f'  und  that,  because  of  the  congressional  mandate  under  which 
UCA  is  being  developed,  the  possibility  of  using  UCA 
hardware  or  facilities  for  OHMIS  is  at  present  precluded. 
Furthermore,  unlike  the  VIABLE  system  described  above, 
almost  none  of  the  data  that  will  be  on  the  UCA  system  will 
be  of  direct  use  to  OHMIS.  For  these  reasons,  the  idea  of 
using  UCA  as  a  host  for  OHMIS  was  determined  to  be 
infeasible. 

o  Air  Force  occupational  health  information  system.  The  Air 
Force  is  presently  developing  an  occupational  health 
management  information  system.  In  order  to  ensure  that  to 
the  extent  possible  all  of  the  advances  and  "lessons 
learned"  by  the  Air  Force  were  incorporated  into  OHMIS, 
interviews  were  held  with  the  developers  of  the  Air  Force 
system.  Several  important  concepts,  especially  on  the 
development  and  deployment  of  an  information  system  such  as 
OHMIS,  were  learned  from  these  interviews.  It  is  suggested 
that  continued  exchange  between  the  DA  and  Air  Force  systems 
be  maintained  throughout  the  development  and  operation  of 
OHMIS.  Although  neither  OHMIS  or  the  Air  Force's  system 
have  been  developed  yet,  it  can  be  stated  at  this  time  that 
integration  of  the  data  between  the  two  systems  is,  in 
principle,  possible.  This  is  because  the  recommended  system 
design  for  OHMIS  is  such  that  it  allows  for  easy  integration 
with  other  data  bases.  If,  for  example,  at  some  time  in  the 
future  it  appeared  desirable  to  combine  the  data  from  the 
two  systems  on  exposure  to  hazards  and  medical  offense  for  a 
selected  population  of  workers  (e.g.,  a  job  class  that  had  a 
relatively  small  number  of  employees  in  both  services),  this 
could,  in  theory,  be  done. 

o  NASA's  Occupational  Health  and  Safety  Information  System 
(OMEHS) .  In  May  1977,  the  National  Aeronautics  and  Space 
Administration  (NASA)  undertook  a  study  to  determine  its 
safety,  env ironmental  health  and  occupational  medicine 
program  data  requirements.  This  project  culminated  in  a 
report,  "Information  Requirements  of  the  National 
Aeronautics  and  Space  Administration's  Safety,  Environmental 
Health,  and  Occupational  Medicine  Programs,"  May  1978.  This 
report  recommended  that  NASA  establish  a  computerized 
information  system  which  would  have  the  following  general 
attributes : 

Serve  both  the  needs  of  NASA  Centers  and  Headquarters 

Provide  computer  terminals  for  all  users 

Be  a  flexible  system  to  accommodate  changes  in 
regulations  and  bookkeeping  requirements 

Contain  an  accident  and  occupational  illness  reporting 
component 
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Contain  an  inventory  of  toxic  chemicals  and  other 
hazardous  substances  used  by  NASA 

Contain  a  system  component  for  workplace  monitoring  and 
survey  data 

Contain  a  records  management  component  to  track  program 
activities,  personnel,  budgets,  and  training. 

This  effort  culminated  in  the  release  of  an  RFP  in  the 
sunnier  of  1981  to  select  a  vendor  who  had  an  "operational" 
system  which  could  be  adapted  to  NASA's  needs.  Five 
proposals  were  submitted,  three  of  which  were  evaluated. 
While  the  exact  cost  figures  involved  are  not  available  on 
the  public  record,  the  estimated  costs  ranged  from  150-30056 
more  than  NASA  had  budgeted  for  the  program.  As  a  result, 
the  procurement  was  cancelled  and  NASA  is  currently 
re-evaluating  its  approach. 

1.2  TASKS  IN  THE  PROJECT 


This  Section  briefly  describes  the  procedures  used  to  conduct  the 
project  during  which  this  report  was  developed.  The  five  tasks 
involved  in  the  performance  of  this  project,  as  outlined  in  the 
project  Contract,  were: 

"A.  Identify  the  Army  Medical  Department's  informational  needs 
relating  to  occupational  health. 

B.  Evaluate  occupational  health  software  already  available 
which  might  support  these  informational  needs. 

C.  Provide  an  analysis  of  these  existing  OH  systems, 
identifying  strengths,  weaknesses,  advantages  and 
disadvantages  of  each. 

D.  Provide  and  describe  which  of  these  systems  are  best  for  the 
stated  informational  needs,  or,  if  a  best  system  cannot  be 
identified,  provide  a  description  of  the  unique  system  which 
should  be  developed. 

E.  Provide  an  estimate  of  the  resource  requirements  of  and 
impact  on  existing  facilities  to  implement  the  recommended 
system. " 

The  specific  approach  employed  to  complete  each  of  the  above  tasks  is 
described  below. 

TASK  A.  One  of  the  specific  subtasks  of  TASK  A  included  the  review 
of  all  Federal,  Department  of  Defense,  Department  of  the  Army,  Office 
of  the  Surgeon  General  and  Health  Services  Command  documents  related 
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to  automation  life  cycle  management,  occupational  health  program 
requirements  and  medical  records  management.  These  documents  took  the 
form  of  regulating  directives,  standards,  standing  operating 
procedures  and  memoranda.  Copies  of  these  documents  were  obtained  and 
reviewed  for  applicable  occupational  health  requirements.  Many  of 
these  documents  are  listed  in  the  REFERENCES  given  at  the  end  of  this 
report.  Section  II  of  this  report  details  the  requirements  identified 
during  the  review  of  these  regulations. 

Another  subtask  of  TASK  A  involved  the  identification  of  the 
informational  needs  through  visits  to  the  five  Army  installations 
listed  below: 


Installation 

Major  Command 

Fort  Leonard  Wood,  MO 

TRADOC 

Fort  Polk,  LA 

FORSCOM 

Fort  Meade,  MD 

FORSCOM 

Aberdeen  Proving  Grounds,  MD 
Walter  Reed  Army  Medical 

DARCOM 

Center,  MD 

HSC 

The  five  installations  which  were  visited  are  operated  by  a  variety  of 
Major  Commands;  this  meant  that  a  full  understanding  of  the  existing 
operations  within  the  Department  of  the  Army  could  be  obtained. 

Points  of  contact  (usually  within  the  Preventive  Medicine  Activity) 
were  arranged  at  each  installation.  These  people  were  then  supplied 
with  a  list  of  the  types  of  persons  that  should  be  interviewed 
during  the  visit.  The  points  of  contact  arranged  appointments  with 
each  of  the  appropriate  types  of  people.  Visit  dates  were  then 
scheduled  at  the  convenience  of  each  installation. 

The  major  purposes  of  these  interviews  were  to  define  the  current 
procedures,  estimate  the  potential  impact  on  OHMIS  and  identify  local 
needs  and  interfaces.  Another  important  aim  was  to  establish  the 
degree  of  user  interest,  involvement  and  acceptance  that  could  be 
expected  for  OHMIS.  This  knowledge  will  provide  a  basis  for  the 
implementation  of  the  OHMIS  in  the  future. 

TASK  B.  Information  system  designers  were  contacted  and  requested 
to  submit  information  about  their  occupational  health  related  systems. 
The  designers  contacted  were  those  who  responded  to  the  request  for 
proposals  by  NASA  (Solicitation  No.  W10-26508/HWC-2 ,  Occupational 
Medicine,  Environmental  Health  and  Safety  (OHEHS)  Information  System) 
since  the  USAEHA  considered  that  proposed  system  as  equivalent  to  the 
type  of  system  envisioned  for  OHMIS.  FIGURE  4-1  lists  the  vendors  and 
systems  reviewed. 

All  of  the  documentation/literature  pertaining  to  these  systems  was 
reviewed  and  evaluated  to  determine  the  potential  of  each  one  as  the 
"best"  system  to  support  the  DA' s  occupational  health  informational 
and  functional  needs  identified  in  TASK  A.  Section  IV  of  this  report 
supplies  the  findings  from  the  review  of  each  system. 
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Also  reviewed  as  a  part  of  TASK  B  were  the  existing  governmental 
occupational  health  systems,  or  partial  systems,  including  the 
Army-wide  and  installation  unique  systems.  These  systems  were 
evaluated  for  their  potential  applicability  and/or  interface  with  the 
0HM1S.  Sections  1.3  and  2.3  discuss  these  governmental  systems. 

TASK  C.  The  evaluation  for  potential  applicability  of  each  existing 
system  to  support  the  informational  and  functional  requirements  of  a 
OA  OHMIS  system  was  then  conducted.  This  was  based  on  the  following 
criteria: 

1.  Cost  of  system  (within  constraints  of  a  Class  IV  system); 

2.  Compatibility  with  proposed  host  hardware; 

3.  Interactive,  on-line  input  and  processing: 

4.  Ability  to  adapt  to  changing  DA  needs  and  constraints; 

5.  Ability  to  utilize  existing  data  sources; 

6.  Ability  to  enhance  the  program  management,  audit  and  quality 
assurance  of  the  Army's  occupational  health  program 

The  results  of  this  evaluation  are  given  in  Section  IV. 

TASK  D.  The  conclusion  of  the  review  and  evaluation  of  each 
available  system  (TASKS  B  and  C)  based  on  the  evaluation  criteria  was 
that  no  existing  system  fulfills  the  minimum  acceptable  performance 
requirements  of  OHMIS.  Therefore,  the  recommended  system  description 
for  OHMIS,  provided  in  Sections  V  through  VIII  of  this  report,  is  a 
functional  description  of  the  new  ("unique")  system  which  should  be 
developed  to  meet  the  Army's  occupational  health  information  needs. 

TASK  E.  Resource  requirements  of  and  impact  on  existing  operations 
to  implement  the  recommended  system  were  prepared,  based  on: 

1.  Research  and  development  costs; 

2.  Investment  costs; 

3.  Operation  and  support  costs. 

Section  VIII  of  this  report  presents  these  resource  requirements  and 
the  system's  impact  on  existing  Army  Medical  Department  facilities. 

1.3  SUMMARY  OF  INTERVIEWS  CONDUCTED 

The  following  discussion  deals  with  the  results  from  the  interviews 
conducted  as  a  part  of  TASK  A  described  above.  As  indicated,  the 


purpose  of  these  interviews  was  to  establish  the  informational  and 
functional  needs  of  the  potential  local  installation  users  and  to 
evaluate  the  constraints  on  and  interest  in  participating  in  OHMIS  by 
these  users.  FIGURE  1-1  shows  a  list  of  the  persons  interviewed.  The 
review  presented  below  is  organized  around  the  types  of  users 
interviewed  and  reviews  the  topics  discussed  during  the  interviews, 
the  significant  findings,  any  problems  affecting  OHMIS  that  were 
identified  and  any  suggestions  about  the  design  of  OHMIS  proposed  by 
the  persons  interviewed.  The  sunmary  of  the  needs  presented  by  each 
type  of  user  is  given  in  Section  2.2. 

1.3.1  Occupational  Health  Nurse 


Being  the  nucleus  and  primary  beneficiary  of  any  occupational  health 
system,  the  Occupational  Health  Nurses  were  the  focal  point  of  much  of 
the  time  spent  during  the  visits  to  the  installations.  The 
individuals  interviewed  were  all  pleased  to  see  the  effort  expended  to 
improve  the  fulfillment  of  the  occupational  health  mission.  They  were 
eager  to  discuss  the  capabilities  or  problems  of  their  current  systems 
and  to  identify  what  they  would  like  to  see  in  a  comprehensive 
occupational  health  management  information  system.  The  following 
details  the  topics  discussed  during  the  interviews  and  the  findings 
from  these  discussions. 

o  Scheduling  of  Occupational  Health  appointments.  The 

Occupational  Health  Nurses  explained  their  current  methods 
of  scheduling  appointments  for  medical  surveillance,  pre¬ 
employment  and  other  routine  medical  exams.  They  also 
explained  how  these  appointments  are  tracked  for  compliance 
and  the  procedures  taken  in  following  up  missed 
appointments. 

The  methods  used  in  the  scheduling  of  exams  involved  a 
variety  of  techniques  including  scheduling  by  birth  month  of 
the  employee  and  by  the  building  or  organization  in  which 
the  employee  primarily  works.  The  procedures  used  in  making 
the  appointments,  although  all  manual  procedures,  also 
varied  considerably.  They  ranged  from  arranging  the 
appointment  for  the  employee  over  the  phone;  notifying  the 
employee  by  mail  that  an  exam  was  due  and  then  having  the 
employee  phone  the  clinic  to  arrange  for  the  appointment; 
notifying  the  supervisor  that  his/her  employees  are  due  for 
exams  and  having  the  supervisor  arrange  with  the  employees 
for  the  day  and  time  of  the  appointment;  assigning  a  time 
period  for  when  an  organization’s  exams  will  be  given  and 
having  the  supervisor  of  the  organization  arrange  for 
his/her  employees  to  phone  the  clinic  to  arrange  for  an 
appointment  during  the  assigned  time  period. 

Tracking  of  appointments  is  also  accomplished  manually  and 
typically  involves  a  phone  call  as  a  follow-up.  One 
installation  compiles  a  list  of  all  "no-shows'  and  forwards 
it  to  the  Post  Commander  for  follow-up  and  compliance 
enforcement . 


FOOTNOTES:  (1)  Market  Street  St.  Louis 

(2)  Goodfellow 

(3)  Cameron  Station 

(4)  Ft.  Detrick 
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Services  provided  by  Occupational  Health.  The  services 
provided  by  the  Occupational  Health  Nurses  were  fairly 
consistent  from  one  installation  to  the  next  in  content, 
e.g.,  in  the  content  of  the  exams.  The  services  included 
conducting  exams,  site  surveys,  personal  protective 
equipment  fittings  and  maintenance  of  medical  records. 
However,  the  scope  (degree  of  implementation)  of  the 
services  did  vary  considerably  between  installations.  For 
example,  at  some  installations,  all  employees  are  tested  as 
a  part  of  the  hearing  conservation  program  while  at  other 
installations  only  those  employees  identified  as  being 
exposed  to  high  hazard  noise  are  included. 

o  Population  served  by  Occupational  Health.  The  boundaries 
of  the  occupational  health  service  area  were  discussed  and 
found  to  be  different  from  the  service  boundaries  of  the 
Civilian  Personnel  Office  in  all  cases.  In  fact,  during  one 
visit,  every  possible  combination  of  boundary  crossover  was 
found  to  exist.  These  differences  in  service  area 
boundaries  are  important  organization  considerations 
affecting  the  design  of  OHMIS.  It  will  be  necessary  to 
choose  which  boundaries  are  to  define  the  local  OHMIS 
service  area.  Possibilities  include  the  installations,  the 
CPO  service  area,  or  the  MEDDAC's  area  of  responsibility. 

The  identification  of  the  individuals  served  within  the 
occupational  health  service  area  is  generally  accomplished 
through  the  use  of  computer  listings  of  active  employees 
from  the  Personnel  Offices  (military  and  civilian).  At  some 
installations,  these  listings  only  include  those  employees 
who  are  in  the  job  classes  which  require  medical 
surveillance.  At  other  installations,  the  listings  include 
everyone  and  the  Occupational  Health  Nurses  use  the  lists  to 
identify  the  individuals  who  should  receive  medical 
surveillance. 

The  segment  of  the  installations'  population  which  receives 
medical  surveillance  (e.g.,  all  employees;  only  employees 
within  job  classes  required  to  have  medical  surveillances; 
employees  within  job  classes  required  to  have  medical 
surveillance  plus  those  employees  within  job  classes  not 
requiring  medical  surveillance,  but  who  are  known  to  have 
hazardous  exposures,  etc.)  is  determined  by  the  Occupational 
Health  activity  based  on  its  individual  understanding  or 
interpretation  of  what  is  required  by  the  DA  occupational 
health  program.  This  understanding/interpretation  varies 
considerably  between  installations. 

o  Interaction  with  Industrial  Hygiene.  This  important 
interaction  was  present  at  most  of  the  installations 
visited,  but  was  generally  considered  to  fall  short  of  its 
potential.  The  interactions  found  to  be  present  between  the 
Industrial  Hygiene  activity  and  the  Occupational  Health 
Nurses  typically  involved  the  sharing  of  survey  information 
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collected  by  both.  Occupational  Health  requests  for 
Industrial  Hygiene  surveys  to  be  performed,  and  Occupational 
Health  requests  for  information  pertaining  to  hazardous 
substances.  A  frequent  complaint  was  that,  since  the  start 
of  LOHHI,  the  interaction  between  OH  and  IH  has 
deteriorated,  especially  with  regard  to  the  transfer  of 
hazard  information  and  the  results  of  surveys  from  IH  to  OH. 

o  Interaction  with  Personnel  (Civilian  (CPO)  and  Military 
(MIlPO) ) 1  The  Personnel  Offices  are  sources  of  valuable 
information  related  to  the  employees  (e.g.,  job  class,  birth 
month,  etc.)  that  is  essential  for  managing  an  occupational 
health  program.  This  source  of  information  had  been 
recognized  by  the  Occupational  Health  Nurses  and 
arrangements  had  been  made  at  all  but  one  installation  to 
utilize  this  source  of  personnel  data.  In  all  cases,  this 
interaction  was  initiated  by  the  Occupational  Health  Nurses. 
The  OHN  would  request  periodic  printouts  of  the  personnel 
data  by  birth  month,  age,  job  class,  etc.  This  data  is  used 
by  the  Occupational  Health  Nurses  to  identify  the  population 
to  be  surveyed  by  the  Occupational  Health  Clinic. 

Another  interaction  with  the  Civilian  Personnel  Office 
involved  the  participation  of  the  OHN  in  the  preparation  and 
processing  of  workers'  compensation  forms  for  injuries/ 
illnesses  incurred  from  job-related  activities. 

o  Other  interactions.  Although  other  possible  interactions 
(e.g.,  with  Facility  Engineers,  Supply,  etc.)  could  benefit 
the  occupational  health  program,  no  such  interactions  were 
found  at  the  installations  visited.  The  exception  was  the 
interaction  with  Safety  with  regard  to  personal  protective 
equipment  monitoring  and  record  keeping. 

o  Records  flow.  The  'flow'  of  the  medical  records  from  the 
time  they  are  originated  to  when  they  are  transferred/ 
retired  upon  termination  of  the  employee  was  discussed  and 
did  not  vary  greatly  from  one  installation  to  the  next. 

o  Workload  of  Occupational  Health.  The  workload  (e.g., 
number  of  exams,  frequency  of  surveys,  etc.)  of  the 
Occupational  Health  Clinic  was  discussed.  It  was  found  to 
be  primarily  a  function  of  the  OHN  activity's  interpretation 
of  OA  policy  on  the  size  of  the  population  to  be  served  and 
the  corresponding  degree  of  implementation  (scope)  of  the 
services  provided.  This  information  is  important  in  the 
sizing  considerations  of  an  OHMIS. 

o  Examples  of  forms.  Copies  of  forms  completed  and/or 

processed  by  Occupational  Health  were  obtained  along  with 
information  on  the  'flow'  of  each  form. 
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Examples  of  printouts.  Copies  of  printouts  (if  any)  used 
by  Occupational  Health  and  information  on  how  the  printouts 
are  generated  and  the  sources  from  which  they  originate. 

1.3.2  Patient  Administration  Division  (PAD) 


This  group  is  the  major  source  of  information  on  the  record  flow  and 
procedures  related  to  military  employee  medical  records.  Also,  this 
Division  described  the  data  flow  for  inpatient  (hospital  based) 
medical  services.  Great  similarity  between  installations  was  found  in 
the  PAD  record  keeping  procedures,  although  some  differences  in 
methods,  especially  storage,  were  observed.  The  following  are  the 
topics  discussed  and  major  findings. 

o  Medical  events  data.  PAD  provides  input  to  the  IPOS 

(Individual  Patient  Data  System).  This  system  records  the 
treatment  and  diagnoses  for  all  inpatient  medical  services 
using  the  ICDA  (International  Classification  of  Diseases, 
Abridged)  coding  system.  Presently,  the  data  is  batch 
processed  and  centrally  maintained  by  HSC  at  Fort  Sam 
Houston;  there  are  plans  for  on-line,  interactive  or  direct 
entry  of  this  data  to  the  IPOS  data  base.  Historical  data 
is  maintained  and  is  available  for  many  past  years.  The 
feasibility  of  OHMIS  accessing  this  data  is  very  high 
because  of  the  centralized  nature  of  the  system. 

A  significant  finding  was  that  there  is  currently  no 
system  equivalent  to  IPOS  for  outpatient  clinic  service 
data,  including  Occupational  Health  Clinic  data.  Outpatient 
medical  service  data  on  diagnosis,  complaint,  treatment  and 
prognosis  is  essential  to  OHMIS  and  is  the  only  source  of 
medical  events  data  (other  than  workers’  compensation  data) 
for  civilian  employees.  The  outpatient  medical  events  data 
is  manually  recorded  on  the  "patient's”  (employee's)  medical 
record;  as  important,  this  data  is  not  coded,  meaning  that 
there  is  no  way  in  which  to  directly  input  existing 
outpatient  medical  events  data  into  a  computer.  In  sumnary, 
the  DA  does  not  have  the  automated  medical  records  system  or 
equivalent  that  is  necessary  to  immediately  process  this 
type  of  data  and  add  it  to  the  OHMIS  data  base.  It  is 
believed  to  be  impractical  to  develop  such  a  system  for  use 
only  by  the  occupational  health  program,  as  an  automated 
medical  records  system  would  impact  all  DA  medical  programs. 
Furthermore,  the  prospect  of  organizing  a  cadre  of 
nosologists  to  code  outpatient  medical  data  in  preparation 
for  entering  it  into  OHMIS  is  impractical  for  economic 
reasons.  On  the  other  hand,  it  does  not  seem  realistic  to 
hold  up  development  of  OHMIS  pending  the  development  of  an 
automated  medical  record  system  or  an  outpatient  information 
system.  Although  there  are  several  ongoing  DA  and  TRISMIS 
efforts  to  develop  an  outpatient  information  system,  one  of 
which  may  bear  fruit,  the  interviews  conducted  during  this 
project  do  not  indicate  that  such  a  system  is  at  all 
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imminent.  Accordingly,  the  recommended  OHMIS  design  is  such 
as  to  allow  the  DA  occupational  health  program  to  use  an 
intermediate  set  of  input  forms  for  collecting  outpatient 
medical  events  data,  developed  by  the  occupational  health 
program.  The  planned  conversion  to  the  eventual ly- to-be- 
developed  outpatient  data  input  system  (e.g.,  an  automated 
medical  record)  is  built  into  the  recommended  system 
design  for  OHMIS  by  the  fact  that  the  same  input,  data 
processing  and  output  procedures  are  expected  to  be  used  for 
al 1  OHMIS  forms  and,  therefore,  conversion  to  a  new  input 
form  is  readily  done. 

As  a  part  of  each  interview  with  outpatient  clinic 
personnel,  the  feasibility  of  having  outpatient  medical 
technicians  complete  the  intermediate  forms  developed  by  the 
occupational  health  program  to  provide  for  medical  events 
data  input  to  OHMIS  was  examined  during  this  project.  This 
feasibility  was  reported  to  be  high.  In  one  interview,  the 
format  for  such  forms  was  suggested  by  the  interviewee  based 
on  the  NIH  system  of  forms  developed  to  address  an 
equivalent  problem.  The  NIH  forms  are  multiple  choice  forms 
consisting  of  the  ICDA  codes  most  frequently  used  by  the 
particular  clinic. 

This  approach  is  recommended  for  OHMIS  because  it  almost 
eliminates  the  coding  problem  (i.e.,  data  comes  to  OHMIS  in 
a  self-coded  format,  except  for  any  open-ended  or  "other" 
categories  on  the  form).  Such  an  approach  requires  the 
development  of  a  separate  outpatient  visit  input  form  for 
each  outpatient  clinic. 

o  Central  appointments/scheduling.  The  current  and  planned 
scheduling  program  (IAS  and  PAS)  used  by  PAD  were  examined. 
The  information  about  these  systems  was  used  in  the 
development  of  the  scheduling  function  of  the  recommended 
system  design  for  OHMIS.  It  was  not  practical  to  simply  use 
the  existing  scheduling  programs  in  the  recommended  OHMIS 
system  design  because  of  the  extensive  interfacing  required 
between  the  scheduling  function  and  the  other  OHMIS  core 
data  processing  functions. 

o  DEERS  (Defense  Eligibility  Reporting  System).  The 

interviewees  at  PAD  frequently  mentioned  the  use  of  DEERS  as 
a  possible  source  of  data  on  employees  for  OHMIS. 
Accordingly,  this  external  data  source  was  examined.  DEERS 
was  subsequently  rejected  as  a  tool  for  OHMIS,  however,  (in 
favor  of  the  military  and  civilian  personnel  systems) 
because:  (1)  it  includes  military  dependents  which  are  not 
covered  by  OHMIS;  (2)  it  does  not  provide  as  much  data  as 
the  other  external  data  sources  on  personnel;  and,  (3)  the 
quality  control  on  DEERS  data  is  reported  to  be  very  low. 

1.3.3  Hearing  Conservation  Officer 

The  existing  Hearing  Conservation  Program  within  the  Army  (HEARS)  has 

t ne  potential  of  being  a  complementary  and  independent  module  of  OHMIS 
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with  very  few  changes.  The  interviews  with  the  Hearing  Conservation 
Officers  at  each  installation  provided  us  with  information  related  to 
the  HEARS  requirements ,  procedures  and  uses  at  the  local  installation 
level.  The  following  are  the  topics  discussed  during  the  interviews 
with  the  Hearing  Conservation  Officers  and  the  findings  from  the 
discussions . 

o  Population  serviced  by  Hearing  Conservation  Program.  The 
populations  which  were  served  by  the  Hearing  Conservation 
Program  and  the  procedures  used  to  identify  the  populations 
were  discussed  and  found  to  vary  greatly  between  the 
installations  visited: 

Some  of  the  installations  were  servicing  all  OA 
personnel  within  the  service  area  of  the  MEDDAC.  This 
population  was  identified  through  personnel  printouts 
of  al 1  employees. 

Other  installations  were  servicing  those  persons  within 
occupations  that  require  hearing  surveillance  according 
to  the  installation's  interpretation  of  OA  guidelines. 
This  population  was  also  identified  through  personnel 
printouts;  printouts  are  requested  that  list  only  those 
persons  working  within  specified  job  classes. 

Still  other  instal lations  were  servicing  only  those 
individuals  who  were  known  to  be  actually  exposed  to 
noise  hazards.  This  population  is  identified  during 
surveys  by  the  Hearing  Conservation  Officer,  Safety  or 
Industrial  Hygiene  or  visits  by  the  Occupational  Health 
Nurses . 

It  was  interesting  to  note,  however,  that  the  compliance 
rate  (the  rate  of  kept  vs.  scheduled  appointments)  was  very 
high  at  all  installations  visited,  regardless  of  the 
population  serviced. 

o  Appointment  scheduling.  For  the  most  part,  the 

appointment  scheduling  as  well  as  the  follow-up  procedures 
involved  telephone  contact. 

o  Testing  and  record  keeping  procedures.  The  testing  ar.d 
retesting  procedures  were  discussed  and  found  to  be  very 
consistent  from  installation  to  instal lation.  In 
particular,  it  was  found  that  abnormal  test  results  (e.g., 
threshold  shifts)  were  routinely  followed  up  with  retesting 
after  prolonged  pe'iods  of  reduced  exposure  to  noise.  If 
the  sir:  ft  was  still  present,  a  complete  audiology  exam  was 
performed. 

It  was  found  tnat  the  hearing  test  documents  are  retained 
for  five  years  from  the  date  of  the  most  recent  test.  It 
was  also  noted  that  approximately  10%  of  all  records  are 
missing  some  sort  of  reference/base  line  data.  Also,  as 
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HEARS  operates,  the  reference/base  line  information  must  be 
manual 1y  located,  copied  onto  a  new  form  and  submitted 
each  time  a  periodic  exam  is  done. 

o  Noise  hazard  surveys.  Noise  hazard  surveys  were  performed 
by  all  of  the  Hearing  Conservation  Officers  interviewed. 
These  surveys  were  performed  annually,  without  notice,  and 
included  the  inspection  for  proper  use  of  appropriate  and 
adequate  hearing  protection. 

o  Interaction  with  Occupational  Health.  Because  much  of  the 
audiology  equipment  is  located  in  the  Occupational  Health 
Clinics  and  because  the  Clinic  staff  administers  many  of  the 
hearing  tests,  coordination  is  required  in  the  timing  of 
periodic  Occupational  Health  exams  and  hearing  tests. 
However,  there  is  often  a  significant  lack  of  coordination 
in  the  scheduling  of  Occupational  Health  versus  hearing 
conservation  appointments.  Instances  where  the  patient  was 
scheduled  for  an  exam  shortly  after  or  bef ot e  a  hearing  test 
do  occur.  One  of  the  needs  that  should  be  addressed  by  the 
OHMIS  scheduling  system  is  the  coordination  of  all  of  the 
actions  (tasks)  involving  the  same  employee  (as  well  as 
those  involving  the  same  facility,  organizational  unit, 
etc.).  The  scheduling  program  needs  to  be  able  to  identify 
those  tasks  already  scheduled  for  an  employee  and  to  "look 
ahead"  to  identify  those  tasks  that  wi 1 1  be  scheduled  in 
the  future  so  that  the  scheduling  of  a  current  task  is 
coordinated  with  previously  scheduled  and  future  tasks.  The 
recommended  system  design  for  the  OHMIS  scheduling  function 
has  these  capabilities. 

o  Interaction  with  Industrial  Hygiene  and  Safety.  Both  the 
Safety  and  Industrial  Hygiene  offices  help  the  Hearing 
Conservation  Officer  through  their  surveys  which  identify 
noise  hazardous  areas  and  noise  exposed  populations. 

o  Testing  equipment.  The  audio  testing  equipment  was 

discussed  and  demonstrated  during  each  interview.  Either 
all  manual  or  manual  and  automated  equipment  was  in  use  at 
eacn  installation.  The  significant  distinctions  noted 
between  the  automated  versus  manual  equipment  was  that  the 
manual  equipment  was  more  "foolproof”  while  '  le  automated 
equipment  has  the  capability  to  tie  directly  into  a  computer 
for  data  manipulation  and  storage. 

o  Examples  of  forms.  Copies  of  the  forms  completed  and/or 

processed  in  the  hearing  conservation  program  were  obtained 
along  with  information  about  the  "flow"  of  each  form. 

1.3.4  Troop  Medical  Clinic 

The  Troop  Medical  Clinics  (TMC)  are  important  to  OHMIS  in  that  they 
are  the  point  of  initial  contact  (treatment  as  well  as  record  keeping) 
for  the  in juries/ i 1 1  nesses  incurred  by,  and  some  of  the  routine 
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medical  services  given  to,  active  duty  military  personnel.  Problems 
with  record  keeping  at  this  critical  first  point  of  contact  greatly 
affect  certain  aspects  of  OHMIS,  e.g.,  assurance  that  al 1 
injuries/illnesses  are  identified.  The  following  are  the  topics 
discussed  during  the  interviews  with  the  Troop  Medical  Clinic 
personnel  and  the  findings  from  the  discussions. 

o  Services  provided  by  Troop  Medical  Clinic.  The  services 
provided  by  the  TMCs  were  discussed  and  included  the 
screening  of  patients,  treatment  of  minor  conditions, 
referrals  to  MEDDAC  hospitals,  and  medical  record 
maintenance  for  the  troops.  The  feasibility  of  asking  the 
TMC  technician  to  use  a  multiple  choice  type  form  to  record 
treatment,  diagnosis  (complaint)  and  prognosis  of  each  visit 
for  use  in  entry  onto  the  OHMIS  data  base  was  discussed.  It 
was  found  to  be  tentatively  feasible  because  a  form  similar 
in  function  to  this  form  are  already  being  used. 

o  Examples  of  forms.  Copies  of  the  forms  completed  and/or 
processed  by  the  TMC  were  obtained  along  with  information 
about  the  "flow"  of  each  form. 


Industrial  Hygienist 


The  Industrial  Hygiene  group  of  OHMIS  users  is  important  to  OHMIS  in 
that  it  is  the  primary  source  of  information  related  to  occupational 
exposures  and  corrective  actions;  these  people  also  play  a  significant 
role  in  the  initial  recognition  of  hazardous  working  environments. 

The  following  is  a  summary  of  the  topics  discussed  during  the 
interviews  with  the  Industrial  Hygienists  and  the  findings  from  these 
discussions. 


o  Services  provided  by  Industrial  Hygiene.  The  services 

performed  by  the  Industrial  Hygiene  activity  at  each  of  the 
installations  visited  included  workplace  surveys, 
identification  of  hazardous  areas  and  technical  support  to 
the  Occupational  Health  and  Safety  activity  in  terms  of 
sampling  and  evaluation  of  occupational  exposures.  All  of 
the  Industrial  Hygienists  interviewed  also  expressed  the 
need  for  and  importance  of  their  input  in  the  review  of  work 
orders  'or  facility  designs  and  changes  and  in  the  selection 
and  review  of  personal  protective  eguipment.  Although  these 
additional  services  were  not  being  provided  by  the 
Industrial  Hygiene  activity  in  all  installations,  all  IH 
staff  interviewed  felt  that  these  were  services  that  they 
should  provide. 

o  Workplace  surveys.  The  scheduling  of  routine  surveys  was 
found  to  be  based  on  either  a  'per  building'  basis,  by 
organizational  unit  or  by  the  potential  severity  of 
exposures  present.  Surveys  are  also  performed  ‘on  requests' 
from  organizational  units.  Safety  or  Occupational  Health. 
LOHHI  surveys  are  also  performed  by  the  Industrial  Hygiene 
activity.  These  surveys  were  behind  schedule  at  most  of  the 
instal  lations  visited.  Although  these  LOHHl  surveys  were 
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intended  to  be  performed  annually,  in  reality  all 
installations  visited  are  requiring  from  2-3  years  to 
complete  the  surveys  for  the  entire  installation.  Many  of 
the  Industrial  Hygienists  questioned  the  usefulness  of  such 
untimely  data.  They  also  were  disappointed  in  the  lack  of 
availability  of  any  of  the  LOHHI  results  at  the  local 
installation  level. 

o  Material  Safety  Data  Sheets.  It  was  found  that  most  of 
the  Industrial  Hygiene  activities  were  not  satisfied  with 
the  current  MSDS  data.  At  some  installations,  the  MSDS  was 
not  used  at  all.  The  most  recurring  complaint  was  that 
frequently  no  MSDS  is  available  on  a  given  material.  When 
this  occurs,  the  Industrial  Hygieni.t  submits  a  request  for 
the  data  directly  to  the  manufacturer.  The  great  delays  and 
paper  work  associated  with  obtaining  the  needed  information 
on  the  chemical  properties  of  hazards  was  a  frequent 
complaint  as  was  the  lack  of  a  systematized  method  for 
processing  this  data. 

o  Interaction  with  Occupational  Health.  The  interviews  with 
the  Industrial  Hygienists  confirmed  the  OHN's  concern  over 
the  need  for  better  communication  between  IH  and  OH.  In 
particular,  it  was  found  that  the  Industrial  Hygienists 
would  like  to  receive  the  results  of  the  medical 
surveillance  exams  performed  by  Occupational  Health.  This 
information  would  allow  Industrial  Hygiene  to  begin  to 
correlate  occupational  exposures  to  medical  conditions  for 
individuals  or  for  groups. 

o  Interaction  with  Safety.  Although  the  importance  of  this 
interaction  was  recognized  by  the  Industrial  Hygienists  at 
each  installation,  very  little  interaction  actually  takes 
place  short  of  the  dissemination  of  survey  results.  This 
exchange  of  survey  information  was  not  systematic  in  the 
installations  visited.  It  was  noted  at  one  installation 
that  the  Industrial  Hygienists  should  have  input  in  the 
determination  of  the  Risk  Assessment  Codes  (RACs)  for 
abatement  actions,  since  the  Industrial  Hygienists  have  the 
expertise  in  occupational  hazard  exposures. 

o  Interaction  with  the  Directorate  of  Facility  Engineers 
(DFE) .  The  Industrial  Hygienists  at  some  installations 
received  copies  of  the  Space  Installation  Reports  from  DFE. 
These  printouts  were  used  to  make  up  survey  schedules  and  to 
determine  priorities  for  workplace  surveys.  It  was  found 
that  the  Industrial  Hygienists  would  also  like  to  receive  a 
'printout1  of  all  work  orders  submitted  to  DFE.  This  would 
allow  Industrial  Hygiene  to  perform  a  design  review  of  the 
proposed  modifications  prior  to  commencement  of  the  work. 

o  Examples  of  forms.  Copies  of  forms  completed  and/or 

processed  by  Industrial  Hygiene  were  obtained  along  with 
information  on  the  'flow'  of  each  form. 
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o  Examples  of  printouts.  Copies  of  printouts  (if  any)  used 
by  Industrial  Hygiene  and  information  on  how  they  are 
originated  and  their  sources  were  obtained. 


1.3.6  Post  Safety 


The  Safety  activity  at  each  installation  is  a  major  source  of 
information  related  to  occupational  hazards,  abatement  actions  and 
occupational  injury  data.  This  activity  is  also  a  potential  OHMIS 
user.  The  interaction  between  Safety  and  Occupational  Health  is 
believed  by  those  interviewed  to  be  important  to  the  success  of  any 
occupational  health  program.  All  of  those  interviewed  within  the 
Safety  activity  at  each  installation  visited  were  all  interested  in 
the  prospect  of  being  a  part  of  the  OHMIS,  largely  because  of  the 
recognized  need  for  easier  exchange  of  information  between  the  two 
groups.  The  following  are  the  topics  discussed  during  the  interviews 
with  the  Post  Safety  Office  and  the  findings  from  these  discussions. 


o  Services  provided  by  Post  Safety.  The  services  provided 
by  the  Post  Safety  activity  at  each  of  the  installations 
visited  included: 


workplace  surveys 

recommendation  of  abatement  actions  and  tracking 
injury/illness  data  maintenance 
safety  training/education 
Each  of  the  services  is  discussed  below. 


o  Workplace  surveys.  Surveys  of  the  workplaces  are 

generally  scheduled  by  activity  and  are  performed  at  least 
annually  with  the  exception,  in  some  cases,  of  the 
Directorates  of  Industrial  Operations  and  Facilities 
Engineers  which  are  surveyed  more  frequently.  Surveys  are 
also  performed  prior  to  the  occupancy  of  a  building  by  an 
activity.  In  addition  to  surveys,  hazards  present  in  the 
work  environment  are  also  brought  to  the  attention  of  the 
Safety  Activity  by  individuals  working  in  the  area. 

o  Abatement  actions.  As  hazards  are  identified  by  the 

Safety  activity  during  workplace  surveys  or  by  individuals, 
the  Safety  activity  will  assign  Risk  Assessment  Codes  (RAC) 
and  recommend  abatement  actions  for  serious  hazards.  The 
monitoring  for  compliance  with  the  recommended  abatement 
actions  is  often  done  during  the  next  workplace  survey 
(e.g.,  the  following  year)  or  it  is  done  as  a  part  of  the 
routine  interaction  with  the  organization. 

o  Injury/illness  data  maintenance.  The  Post  Safety  activity 
is  responsible  for  maintaining  data  related  to  occupational 
injuries/illnesses  occurring  to  personnel.  This  includes 
generating  the  injury  reports  and  the  OSHA  Logs. 
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o  Safety  train ing/education.  The  Post  Safety  activity 

usually  provides  general  inbriefing  of  new  personnel  about 
the  services  provided  by  the  Safety  activity.  Specific 
safety  procedures  related  to  a  job  are  taught  to  personnel 
by  the  line  supervisor.  Safety  meetings  are  also  regularly 
held. 

o  Personal  protective  equipment  selection.  Although  not  in 
effect  at  all  installations,  all  of  the  Safety  activities 
interviewed  agreed  that  their  office  should  have  input  into 
the  selection  and  assignment  of  personal  protective 
equipment. 

o  Interaction  with  Occupational  Health.  This  interaction 

was  found  to  be  very  limited  in  all  installations.  Little 
more  than  the  transfer  of  injury/illness  or  (occasionally) 
survey  data  takes  place.  In  most  cases.  Safety  allowed  the 
OHN  to  be  responsible  for  personal  protective  equipment 
monitoring  and  for  observation  of  employee  work  practices. 

o  Interaction  with  Industrial  Hygiene.  This  interaction 

seldom  involved  more  than  the  occasional  sharing  of  survey 
results  and  request  by  Safety  for  technical  support  from  the 
IH  related  to  hazardous  materials. 

o  Interaction  with  Department  of  the  Army's  Safety  Center. 

A1 1  of  the  Safety  activities  interviewed  saw  little 
benefit  from  the  printouts  generated  by  the  Safety  Center. 
Desires  for  comparative  data  from  other  installations  and 
access  at  the  local  installation  level  were  noted. 

o  Examples  of  forms.  Examples  of  forms  completed  and/or 
processed  by  Post  Safety  were  obtained  along  with 
information  on  the  'flow'  of  each  form. 

o  Examples  of  printouts.  Copies  of  printouts  used  by  Post 
Safety  and  information  on  how  they  are  originated  and  their 
sources  were  obtained. 

1.3.7  MEDDAC  Safety 

In  addition  to  the  Post  Safety  Office,  the  Safety  Office  within  each 
MEDDAC  was  interviewed  in  order  to  learn  of  the  procedures  of  a  Safety 
Office  at  the  organizational  unit  level.  These  procedures  are  impor¬ 
tant  in  order  that  the  interactions  and  delineation  of  responsibili¬ 
ties  between  the  Post  Safety  activity  and  the  organizational  units' 
Safety  Offices  may  be  defined  and  understood.  The  topics  which  were 
discussed  with  MEDDAC  Safety  Office  were  the  same  as  those  discussed 
with  the  Post  Safety  Office.  The  following  are  the  differences  found 
between  the  two  levels  in  operating  procedures. 

o  Workplace  surveys.  In  many  case,  the  Safety  Office  within 
each  MEDDAC  schedules  monthly  surveys  and  has  a  program 
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to  recognize  deficiencies  on  a  day-to-day  basis.  For  the 
most  part,  abatement  of  deficiencies  were  said  to  be 
arranged  verbally  and  monitored  through  informal  means. 

o  Abatement  actions.  The  MEDDAC  Safety  Office  cites 

deficiencies  ,  evaluates  them  and  recommends  abatement 
actions.  Reports  covering  the  deficiency  and 
recommendations  are  submitted  to  Post  Safety  for  monitoring 
for  compliance  with  the  recommended  abatement  actions. 

o  Injury/illness  data  maintenance.  The  MEDDAC  Safety  Office 
is  responsible  for  collecting  and  maintaining  data  on 
injuries/illnesses  incurred  by  MEDDAC  personnel.  The  MEDDAC 
Safety  Office  submits  copies  of  these  reports  to  the  Post 
Safety  Office. 

Because  it  is  within  the  MEDDAC,  which  is  the  source  of  most 
information  on  the  treatment  of  occupational  injuries/ 
illnesses,  the  MEDDAC  Safety  Office  has  convenient  access  to 
outpatient  logs  and  admission/disposition  records  which  help 
to  identify  job-related  injuries/illnesses.  Many  of  the 
MEDDAC  Safety  Officers  had  recognized  the  value  of  this 
information  and  used  it  to  help  assure  that  all  occupation- 
ally  related  cases  were  identified. 

1.3.8  Chemical  Systems  Lab  Safety  Office 

The  Safety  Office  within  the  Chemical  Systems  Lab  at  Edgewood 
(Aberdeen  Proving  Grounds)  was  interviewed  to  discuss  the  Work  Hazard 
Identification  Control  System  (WHICS).  This  system  was  identified 
during  interviews  at  Fort  Meade.  This  was  the  only  computer  based 
occupational  health  information  system  found  at  any  of  the  five 
installations  visited.  Section  2.3  describes  the  WHICS  system  and 
reviews  its  potential  applicability  to  the  proposed  OHMIS. 

1.3.9  Military  Personnel  Office  (MILPO) 

The  proposed  OHMIS  will  monitor  the  occupational  health  services 
provided  to  all  active  duty  military  personnel  within  the  continental 
Department  of  the  Army  (CONUS).  The  Military  Personnel  Office  is  a 
major  existing  source  of  data  on  each  military  employee.  Because  of 
this,  at  each  installation  a  person  from  MILPO  was  interviewed  to 
determine  the  feasibility  of  'sharing'  this  important  data  with  OHMIS. 
Also  of  interest  were  the  types  of  data  currently  held  on  each 
individual  and  the  current  data  processing  procedures.  The  following 
are  the  topics  discussed  during  the  interviews  with  the  Military 
Personnel  Office  and  the  findings  from  the  discussions. 

o  Military  personnel  data.  The  company  systems  used  to 
process  the  military  personnel  data  at  the  local 
(retaliation  level  (SIDPERS)  as  well  as  at  DA  level 
(MILPRSN)  were  discussed  to  identify  the  types  of  data 
available.  Also  discussed  were  the  processing  cycles  and 
procedures,  data  flow,  and  archiving  process.  Copies  of  the 
forms,  printouts  and  computer  program  manuals  of  SIDPERS  and 
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MILPRSN  were  obtained.  The  feasibility  of  routinely 
abstracting  data  from  the  personnel  data  base  for  use  in 
OHMIS  was  established.  One  of  the  major  current  problems 
with  the  military  personnel  data  systems  (and  their  civilian 
counterparts)  is  that  historical  data  is  not  maintained. 

An  occupational  health  program  requires  historical  data  on 
employees  (e.g.,  changes  in  job  classes)  to  be  maintained. 
Therefore,  OHMIS  must  not  only  abstract  the  information  from 
the  external  personnel  information  systems,  but  also  store 
the  history  of  employee  characteristics  data  on  an 
individual  in  such  a  way  that  future  inputs  from  the 
external  data  sources  of  personnel  data  may  be  added  to 
(not  merely  replace)  previous  data  on  the  same  individual. 

o  Service  area.  The  geographic  service  area  of  the  Military 
Personnel  Office  and  that  of  the  Occupational  Health  Clinic 
were  compared  because  any  disparity  is  believed  to  be  an 
important  consideration  in  defining  the  configuration  of  the 
OHMIS  service  areas.  At  every  installation  visited,  the 
service  area  of  the  Military  Personnel  Offices  interviewed 
and  that  of  the  Occupational  Health  Clinics  were  different. 

o  Job  descriptions  reviews.  The  information  on  job 
descriptions,  i.e.,  the  data  pertaining  to  what  an 
individual  actually  does  in  the  performance  of  his/her  job 
is  of  great  importance  to  many  aspects  of  any  OHMIS.  Many 
data  functions  will  depend  on  the  classification  of  jobs  by 
various  factors  such  as  types  of  hazard  exposures. 
Accordingly,  the  availability  of  this  type  of  data  was 
evaluated  at  each  personnel  office  visited.  Although  job 
description  reviews  are  performed  for  military  personnel, 
"malutilization"  and  outdated/inaccurate/exaggerated  job 
descriptions  for  military  personnel  were  said  to  exist  to  a 
considerable  extent  at  all  of  the  installations  visited. 

This  means  that  any  assumptions  about  an  employee's  hazard 
exposures  that  are  based  on  job  classification  information 
is  questionable. 

1.3.10  Post  Civilian  Personnel  Office  (CPO) 

The  proposed  OHMIS  will  monitor  the  occupational  health  services 
provided  to  all  Department  of  the  Army  Civilian  (OAC)  employees.  The 
Civilian  Personnel  Office,  which  provides  personnel  services  for  these 
employees,  is  envisioned  as  both  a  source  of  employee  data  and  as  a 
potential  OhMIS  user.  The  interviews  were  conducted  to  determine  the 
feasibility  of  utilizing  the  external  source  of  data  on  personnel 
generated  by  this  office,  what  types  of  data  are  currently  available, 
and  the  current  data  processing  procedures.  The  following  are  the 
topics  discussed  during  the  interviews  with  the  Civilian  Personnel 
Office  and  the  findings  from  the  discussions. 

o  Civilian  personnel  data.  The  computer  systems  which 

process  the  civilian  personnel  data,  the  types  of  data  cur¬ 
rently  available  on  these  systems,  and  the  records  flow  from 
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pre-employment  through  transfer/termination  were  discussed 
with  regard  to  the  local  installation  and  DA  level.  The 
processing  cycles  and  procedures  at  the  installation  level 
system  (SCIPMIS,  i.e.,  the  Standard  Civilian  Personnel 
Management  System)  and  the  interface  with  the  DA  level 
system  (CIVPERSINS,  i.e.,  the  Civilian  Personnel  Information 
System)  were  also  discussed.  This  included  a  review  of  the 
several  alternate  personnel  systems  currently  used  by 
individual  organizational  units  in  the  DA,  e.g.,  the  Corps 
of  Engineers. 

o  Service  area.  The  difference  between  the  geographic 

service  area  of  the  Civilian  Personnel  Office  and  that  of 
the  Occupational  Health  Clinic  is  an  important  consideration 
to  the  configuration  of  the  OHMIS  service  areas.  The 
service  areas  of  the  CPOs  interviewed  and  of  the  Occupa¬ 
tional  Health  Clinics  did  not  match  at  any  installation 
visited. 

o  Interaction  with  Occupational  Health.  The  Civilian 
Personnel  Offices  at  most  of  the  installations  visited 
supply  the  Occupational  Health  Clinic  with  rosters  of 
employees  to  receive  medical  surveillance.  The  Occupational 
Health  Clinic,  in  turn,  determines  fitness  for  duty  and 
monitors  occupational  health  through  periodic  exams  of  these 
individuals.  The  CPO  also  submits  to  the  Occupational 
Health  Nurses  copies  of  diagnosis/treatment  reports 
pertaining  to  job  related  injuries/illnesses  which  are 
completed  by  private  physicians.  The  OHN,  in  some 
installations,  participates  in  the  completion  of  workers' 
compensation  forms. 

o  Injury/i llness  data  maintenance.  The  procedures  and 

records  flow  of  the  workers'  compensation  forms,  which  the 
CPO  is  responsible  for  completing,  were  discussed. 

o  Examples  of  forms.  Copies  of  forms  completed  and/or 

processed  by  the  Civilian  Personnel  Office  were  obtained 
along  with  information  on  the  'flow'  of  each  form.  The 
computer  processing  manuals  on  SCIPMIS  and  CIVPERSINS  were 
obtained  and  reviewed. 

o  Examples  of  printouts.  Sample  copies  of  printouts  used  or 
generated  by  the  Civilian  Personnel  Office  and  information 
on  how  they  are  generated  and  used  and  their  sources  were 
obtained. 

1.3.11  MEDDAC  Civilian  Personnel  Office 

Because  MEDDACs  are  tenant  units  residing  on  installations  held  under 
other  Major  Commands  (e.g.,  FORSCOM,  TRADOC,  etc.),  each  MEDDAC  has  a 
liaison  who  interacts  with  the  Post  Civilian  Personnel  Office  with 
regard  to  civilian  personnel  matters  within  the  MEDDAC.  These 
liaisons  were  interviewed  to  define  their  role  in  the  personnel  data 
flow  and  the  interaction  with  the  Post  Civilian  Personnel  Office. 
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1.3.12  Non-Appropriated  Funds  (NAF)  Personnel  Office 


Also  serviced  by  the  proposed  OHMIS  are  the  individuals  designated  as 
Non-Appropriated  Funds  personnel.  Therefore,  a  person  from  the 
Non-Appropriated  Funds  Personnel  Office  was  interviewed  at  each 
installation.  The  following  are  the  topics  discussed  during  these 
interviews  and  the  finding  from  the  discussions. 

o  Non-Appropriated  Funds  Personnel  data.  The  types  of  data 
collected  on  each  NAF  employee  was  discussed  as  well  as  the 
processing  procedures  from  pre-employment  physicals  to 
termination/transfer .  No  computer  systems  were  found  to 
exist  for  processing  of  NAF  personnel  data. 

o  Service  area.  Again,  it  was  found  that  the  service  areas 
of  the  NAF  Personnel  Offices  interviewed  and  those  of  the 
corresponding  Occupational  Health  Clinics  did  not  match. 

o  Interaction  with  Occupational  Health.  Although  totally 
manual,  similar  systems  to  that  of  CPO  for  notifying 
Occupational  Health  of  those  NAF  employees  requiring  medical 
surveillance  are  in  effect.  Occupational  Health  performs 
preplacement  and  periodic  exams  of  those  NAF  employees 
identified  for  medical  surveillance. 

o  Injury/illness  data  maintenance.  The  NAF  Personnel  Office 
is  self-insured  for  workers'  compensation  and,  therefore, 
has  completely  different  procedures  and  forms  pertaining  to 
occupational  injuries/i 1 Inesses. 

o  Examples  of  forms.  Copies  of  forms  completed  and/or 

processed  by  the  NAF  Personnel  Office  were  obtained  along 
with  information  on  the  'flow'  of  each  form. 

o  Examples  of  printouts  Sample  copies  of  printouts  used  by 
the  NAF  Personnel  Office  and  information  related  to  their 
origin  was  obtained. 

1.3.13  Directorate  of  Facility  Engineers 

The  Directorate  of  Facility  Engineers  was  interviewed  at  each 
installation  as  a  source  of  data  on  facilities  and  the  work 
environment:  a  crucial  part  of  any  occupational  health  information 
system.  The  purpose  of  these  interviews  was  to  determine  the 
feasibility  of  'sharing'  this  facilities  data  base  with  the  OHMIS  data 
base,  and  to  identify  the  data  which  is  currently  available  and  the 
current  data  processing  procedures.  The  feasibility  of  routinely 
abstracting  facilities  data  for  use  of  OHMIS  was  established.  The 
following  are  the  topics  discussed  during  the  interviews  with  the 
Directorate  of  Facility  Engineers  and  the  findings  from  the 
discussions . 
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Facility  data.  The  computer  system  which  processes 
facility  data,  the  Integrated  Facilities  System  (IFS),  was 
discussed  with  regard  to  the  data  currently  available, 
including  history  and  archiving,  capabilities  of  the  system, 
processing  procedures  and  data  flow.  Differences  in  the 
processing  procedures  or  system  capabilities  for  DARCOM 
installations,  which  were  the  last  to  utilize  IFS,  were 
discussed  during  the  Facility  Engineer  interviews  at  the  one 
DARCOM  installation  visited.  An  important  finding  was  that 
there  is  no  existing  data  system  for  linking  employees  to 
their  work  site.  This  type  of  information  is  crucial  to  an 
OHM IS  system  and  is  one  of  the  major  types  of  new  data 
that  will  need  to  be  supplied  by  the  OHMIS  system.  What  is 
needed  is  a  system  for  notifying  OHMIS  of  changes  in 
personnel  status  (e.g.,  changes  in  job  class)  that  should 
trigger  a  check  to  determine  if  this  status  change  also 
means  a  change  in  the  location  of  the  employee.  Also,  the 
OHMIS  system  should  be  designed  so  that  every  contact 
between  a  DA  employee  and  the  occupational  health  program 
includes  collection  of  data  on  the  current  work  location  of 
the  employee.  The  recommended  system  design  for  OHMIS 
enables  these  functions  to  be  performed  by  OHMIS. 

o  Work  orders.  Work  order  data  (i.e.,  data  on  requests  for 
modifications/repairs/additions  to  facilities)  is  important 
to  the  OHMIS  because  it  identifies  changes  to  the  work 
environment  and  thereby  changes  to  the  employees'  exposures. 
Work  order  data  also  provides  a  means  of  monitoring  whether 
abatement  actions  have  been  implemented.  The  procedures  for 
processing  this  data  and  the  data  flow  for  work  orders  were 
discussed.  Also  discussed  was  the  method  of  classifying 
work  orders  as  'safety  related'.  This  has  two  aspects:  (1) 
A  work  order  can  be  generated  as  a  result  of  a  need  to 
address  an  existing  safety/health  problem.  (There  is  a 
method  for  identifying  these  work  orders,  but  the  quality 
control  oi  this  classification  of  work  order  is  reported  by 
all  to  be  very  poor.);  (2)  The  change  made  in  the  work 
environment  as  the  result  of  a  work  order  can  affect  the 
safety/health  of  the  work  environment.  (There  is  no 
systematic  method  for  identifying  this  type  of  work  order 
although  all  IH  personnel  interviewed  indicated  the  need  for 
a  notification  system  about  work  orders  that  would  trigger 
an  investigation  by  the  IH  to  determine  the  effects  of  the 
change  in  the  work  environment  covered  by  the  work  order). 

o  Examples  of  forms.  Copies  of  forms  completed  and/or 
processed  by  the  Directorate  of  Facility  Engineers  were 
obtained  along  with  information  on  the  'flow'  of  each  form. 
Copies  of  the  manuals  on  IFS  were  also  obtained  and 
reviewed. 

o  Examples  of  printouts.  Sample  copies  of  printouts 

generated  or  used  by  the  Directorate  of  Facility  Engineers 
were  obtained. 
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1.3.14  Directorate  of  Industrial  Operations  -  Supply 

The  Directorate  of  Industrial  Operations  -  Supply  is  another  source  of 
OHMIS  data.  This  organization  provides  data  on  supplies  which  can  be 
used  as  the  primary  external  data  source  for  data  related  to  hazardous 
materials.  The  interviews  were  conducted  to  determine  the  feasibility 
of  utilizing  this  source  of  existing  data,  the  types  of  data  currently 
available,  and  the  current  data  processing  procedures.  The 
following  are  the  topics  discussed  during  the  interviews  with  the 
Directorate  of  Industrial  Operations  -  Supply  and  the  findings  from 
the  discussions. 

o  Supply  data.  The  Standard  Army  Intermediate  Level  Supply 
System  (SAILS)  is  the  computer  system  which  processes  the 
supply  data  at  each  installation.  SAILS  was  discussed  and 
information  pertaining  to  the  types  of  data  available, 
procedures  for  processing,  and  system  capabilities  was 
obtained.  An  important  finding  was  that  there  is  no 
existing  external  data  source  for  data  linking  supply 
(hazards)  data  to  the  location  in  which  the  item  is  used  or 
stored.  This  type  of  linking  data  is  crucial  to  an  OHMIS 
system  and  is  currently  partially  supplied  by  the  LOHHI 
system.  However,  the  fact  that  there  is  no  external  data 
source  that  tracks  the  location  of  supplies  means  that  the 
current  major  weakness  of  LOHHI  will  need  to  be  solved  by 
OHMIS.  (Specifically,  OHMIS  will  need  to  resolve  the 
problem  of  the  untimeliness  of  the  LOHHI  data  that  is  due  to 
the  lack  of  a  method  of  incremental 1y  updating  the  data, 
that  is,  updating  it  as  changes  in  hazards  occur.  What  is 
required  is  a  method  for  notifying  the  Industrial  Hygienist 
of  the  need  for  a  check  for  changes  in  exposures  to  hazards 
that  is  automatically  triggered  by  information  that  _[s 
available  for  external  data  sources,  such  as  information  on 
the  supplies  ordered  by  an  organizational  unit.  An 
automated  system  for  doing  this  is  provided  in  the 
recommended  system  design  for  OHMIS.  The  forms,  printouts 
and  computer  processing  manuals  (including  the  code  books) 
for  SAILS  were  obtained  and  reviewed. 

o  Local  purchases.  Procurement  of  nonstandard  materials  was 
discussed  and  found  to  be  very  difficult  to  monitor  through 
current  procedures.  It  was  explained  that  materials  could 
be  purchased  without  documentation  on  SAILS  or  any  other 
system. 

o  Hazardous  materials.  The  identification  and  tracking  of 
hazardous  materials  was  discussed  during  each  of  the 
interviews.  It  was  noted  that  a  limited  means  of 
identifying  hazardous  materials  through  the  coding  system 
used  in  SAILS  does  exist. 

1.3.15  Management  Information  Systems  Office  (MISO) 

As  the  potential  host  of  the  OHMIS  software,  the  MISO  was  interviewed 
to  evaluate  the  feasibility  of  the  OHMIS  being  maintained  by  MISO  as 
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compared  to  being  maintained  within  each  MEDDAC.  The  reaction  to  the 
prospect  of  operating  another  system,  even  with  the  expected  size  of 
OHMIS,  was  favorable  for  the  most  part.  The  following  are  the  topics 
discussed  during  the  interviews  with  the  M I  SO  and  the  findings  from 
the  discussions. 

o  Hardware  configuration.  The  installations'  current 
hardware  configurations  were  discussed  as  well  as  the 
possible  conversion  to  the  VIABLE  network.  All  but  one  of 
the  installations  visited  are  scheduled  to  receive  the 
VIABLE  configuration  and  software.  The  approach  of  having 
the  OHMIS  reside  on  VIABLE  was  discussed  with  each  of  the 
MISO  directors  and  was  uniformly  declared  to  be  "the  way  to 


o  Software  systems  currently  operated  by  MISO.  Lists  of  the 
Standard  Army  Systems  and  the  systems  unique  to  each 
installation  were  obtained  along  with  descriptions  of  the 
purpose  and  capabilities  of  each  system.  The  potential 
interface  between  OHMIS  and  many  of  these  software  systems 
was  also  discussed.  It  was  noted  that  extraction  of  data 
through  the  utilization  of  'front  or  rear  end  programs' 
would  be  possible.  The  feasibility  of  generating 
'byproduct'  tape  data  for  OHMIS  from  other  external  data 
sources  on  the  base  operations  computer  systems  was 
supported  by  all. 

1.3.16  Environmental  and  Energy  Conservation  Division  (EECD) 

This  team  of  individuals  is  a  source  of  data  pertaining  to  accidental 
exposures  (e.g.,  spills)  to  hazardous  substances  within  the 
installation.  The  team  was  identified  through  other  interviews  and 
was  only  found  one  of  five  installations  visited.  The  following  are 
the  topics  discussed  during  the  interview  with  the  Environmental  and 
Energy  Conservation  Division  and  the  findings  from  the  discussions. 

o  Services  provided  by  EECD.  This  team  of  engineers  and 
emergency  response  personnel  (e.g.,  firefighters)  is 
responsible  for  responding  to  accidental  hazardous 
exposures.  They  evaluate  and  document  the  circumstances  and 
impact  of  this  type  of  incident,  both  to  the  environment  and 
to  personnel  (including  themselves).  The  resulting  data  on 
hazardous  exposures  would  be  a  valuable  supplement  to  the 
routine  exposure  data  collected  in  OHMIS. 

o  Examples  of  forms.  Copies  of  the  forms  completed  and/or 
processed  by  the  EECD  were  obtained  along  with  information 
on  the  'flow'  of  each  form. 

1.3.17  Comptrol ler 

The  Comptroller  at  each  MEDDAC  was  interviewed  as  a  source  of 
information  for  defining  tne  MEDDAC' s  service  area  boundaries.  This 
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information  is  necessary  in  defining  the  OHMIS  network  configuration. 
The  following  are  the  topics  discussed  during  the  interviews  with  the 
Comptroller  and  the  findings  from  these  discussions. 


o  Service  area  boundaries.  The  service  area  within  the 
responsibility  of  each  MEDDAC  was  defined  during  the 
interview.  This  boundary  was  then  related  to  the  similar 
service  area  boundaries  for  the  Personnel  Offices.  The 
boundaries  were  found  to  be  different  in  all  cases  and  every 
possible  combination  of  overlapping  boundaries  was  observed. 

o  Table  of  Distribution  and  Allowances.  The  Comptroller  was 
also  used  as  a  source  of  information  on  the  procedures 
involved  in  the  assignment  of  personnel  and  in  the 
class  if ication  of  personnel. 


i 
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SECTION  II  -  IDENTIFICATION  OF  OHMIS  FUNCTIONAL  REQUIREMENTS 

AND  NEEDS 


II.  IDENTIFICATION  OF  OHM  IS  FUNCTIONAL  REQUIREMENTS  AND  NE EDS 


In  this  Section,  the  various  functional  requirements  and  needs  that 
must  be  met  by  OHM  I S  are  described.  Three  sources  wer^  used  to 
identify  the  needs  of  the  DA  in  an  occupational  health  information 
system:  (1)  the  requirements  for  an  OHMIS  implied  by  occupational 
health  and  automated  data  management  regulations;  (2)  the  needs 
expressed  by  the  potential  users  of  OHMIS;  and,  (3)  the  needs  that 
arise  from  some  of  the  problems  or  favorable  features  of  the  current 
DA  information  systems. 

The  needs  identified  in  this  Section  are  used  to  develop  the  use 
modules  described  in  Section  III  on  which  the  design  of  OHMIS  is 
based. 

2.1  REGULATORY  REQUIREMENTS 


Two  types  of  regulations  were  reviewed  to  identify  the  functional 
needs  of  OHMIS.  These  were:  (1)  occupational  health  regulatory 
requirements;  and  (2)  DA  requirements  concerning  the  automation  life 
cycle  management  process. 

2.1.1  Occupational  Health  Regulatory  Requirements 

To  ascertain  the  data  requirements  applicable  to  OHMIS,  a  careful 
examination  was  made  of  all  known  applicable  Department  of  Defense, 
Department  of  the  Army  and  Department  of  Labor  Directives,  Instruc¬ 
tions,  Regulations  and  Standards.  The  potential  data  requirements  of 
each  of  these  documents  were  extricted,  categorized  and  compiled  into 
a  generic  list  of  data  types.  The  subsequent  recommended  system 
design  for  OHMIS  is  structured  to  handle  each  data  item  and  the  inter 
action  between  data  items.  It  will  be  necessary  to  load  the  actual 
requirements  into  the  OHMIS  data  base  prior  to  operation  of  OHMIS  and 
to  establish  the  user  procedures  for  periodically  updating  these 
requirements  data.  The  data  processing  (input,  change,  delete, 
examine)  for  handling  requirements  data  (as  distinguished  from  the 
user  procedures)  is  contained  in  the  recommended  system  design  for 
OHMIS.  This  includes  the  data  processing  required  for  having  the 
OHMIS  system  automatically  identify  when  requirements  are  applicable 
and  trigger  and  schedule  the  actions  (tasks)  associated  with  these 
requirements . 

The  generic  list  of  data  items  needed  for  identifying  and  monitoring 
requirements  is  outlined  below.  The  core  data  processing  functions 
for  handling  requirements  in  the  recommended  system  design  for  OHMIS 
have  been  designed  to  input  these  data  elements,  to  trigger  the 
required  actions  based  on  the  values  for  these  data  elements,  and  to 
monitor  completion  of  the  required  actions. 


o  Training  requirements  may  need  data  on: 


The  nature  of  the  work  of  assignment; 

The  nature  of  the  equipment  or  materials  used; 

The  action  level  for  the  substance  or  material  involved 
(i.e.,  for  those  persons  exposed  to  a  substance  at  or 
above  'X'  level); 

Initial  and  recurring  requirements  (i.e.,  an  initial 
training  requirement  1 X '  days  before  assignment  and 
then  repeated  after  fixed  or  variable  time  periods). 

The  data  elements  required  for  specifying  requirements  in 
each  of  these  formats  must  be  included  in  OHMIS. 

o  The  curriculum  of  training  programs  may  need  data  on: 

The  nature  of  the  work  assignment; 

The  engineering  controls  in  place; 

The  contents  of  formal  safety  programs; 

The  type  of  medical  monitoring  in  place. 

o  Licensing  and  certif ication  data  needs  include: 

One-time,  initial  and  recurring  certification  and 
recertification; 

The  nature  of  the  work  and  materials. 

o  Workplace  inspections  and  monitoring  may  include  the 

following  types  of  requirements  and  the  corresponding  data 
elements : 

Specific  test  requirements  based  on  substances 
involved ; 

Accurate  requirements  within  'X'  percent  based  on 
substances  involved; 

Specific,  fixed  time  interval  schedules; 

Varying  schedules  based  on  monitoring  results  (the 
frequency  may  be  increased  to  'X'  intervals  and  shall 
continue  until  at  least  'X'  consecutive  measurements 
taken  * Y '  days  apart  are  below  the  action  level); 

The  need  to  initiate  or  increase  medical  monitoring 
when  an  action  level  is  reached  and  to  suspend  or 
decrease  the  medical  monitoring  when  the  action  level 
is  no  longer  exceeded; 
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The  need  to  notify  employees  at  ‘X*  action  level; 

The  need  to  recognize  changed  monitoring  requirements 
when:  processes  or  materials  change,  controls  change, 
or  personnel  are  added  or  deleted; 

The  need  to  monitor  the  calibration  of  monitoring 
equipment  at  fixed  or  varying  intervals; 

The  need  to  record  workplace  discrepancies  and  monitor 
the  status  of  corrective  actions; 

The  need  to  maintain  records  of  monitoring  activities 
which  may  include:  dates,  duration,  location,  and 
results  of  samples  taken;  descriptions  of  procedures 
used  to  obtain  representati ve  samples;  identification 
of  employees  to  whom  the  sample  applies  and  identifica¬ 
tion  of  the  type  of  personal  protective  equipment,  if 
any,  in  use  at  the  time;  and  potential  environmental 
variables  which  may  affect  the  sample; 

Records  retention  variables  include  storing  the  data 
for  'X1  years  or  duration  of  employment  plus  'Y‘  years, 
whichever  is  longer. 

Medical  surveillance  requirements  may  vary  depending  on  data 
input  to  the  system  about: 

Simple  exposure  to  a  substance  or  energy,  or  exposure 
over  'X'  time  and  at  ' Y*  level; 

Potential  exposure  to  'X1  substance  or  energy. 

Variation  in  the  requirements  for  frequency  and  type  of 
medical  examinations  are  specified  in  the  following  terms  or 
formats : 

By  age; 

Duration  of  exposure; 

Results  of  a  specific  test(s); 

'X'  days  after  initial  employment  before  initial 
assignment; 

At  'X'  intervals  as  specified  in  a  standard  or 
regulation; 

Upon  detection  of  a  symptom; 

An  injury  or  illness  requiring  'X'  amount  of 
hospitalization  of  1 Y '  days  away  from  work; 


I 

'X1  months  preceding  termination  of  employment;  |f 

As  dictated  by  workplace  monitoring;  _ 

By  discovery  of  an  abnormality  and/or  removal  from  ■ 

exposures. 

o  Retention  of  medical  records  may  vary  by  duration  of  \ 

employment  or  termination  plus  'X'  years  as  dictated  by 
employment  exposures 

o  Documentation  concerning  the  use  of  hazardous  materials 
should  include: 

Identification  of  the  substance; 

Amount  involved; 

Where  used; 

How  long  used; 

Retention  of  data  for  'X1  years  depending  on  the 
substance. 

o  Occupational  illness  reporting  requirements  include: 

Diagnosis  categories; 

Severity  in  terms  of  fatalities,  lost  work  days, 
restrictions  to  normal  work  activities,  terminations  or 
transfers; 

Causal  factors; 

Rates  by  man-hours  worked. 

2.1.2  Automation  Life  Cycle  Management  Regulatory  Requirements 

To  ensure  the  development  of  cost  effective  and  standardized  automated 
data  systems,  the  Army  has  promulgated  a  series  of  Army  Regulations  and 
Technical  Bulletins  which  set  forth  Army  policies  and  technical 
requirements.  The  development,  deployment,  and  operation  of  OHMIS  must 
consider  and  apply  each  applicable  provision.  Outlined  below  is  a 
synopsis  of  the  applicable  Army  documents  which  have  applied  to  the 
system  design  outlined  herein: 

o  AR  18-1,  Army  Automation  Management  -  Describes  the  basic 
policies  and  responsibilities  for  the  management  of  Army 
automation. 

o  AR  18-12,  Catalog  of  Standard  Data  Elements  and  Codes  - 
Prescribes  approved  data  elements  for  use  in  all  Army 
information  and  data  systems. 
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o  AR  105-22,  Telecommunication  Requirements  Planning, 

Developing,  and  Processing  -  Provides  the  procedures  for 
submission,  validation  and  approval  of  ADP  telecommunications 
requirements. 

o  AR  340-2,  Maintenance  and  Disposition  of  Records  in  TOE  Units 
of  the  Active  Army,  the  Army  Reserve,  and  the  Army  National 
Guard  -  Prescribes  the  disposition  of  personnel,  inspection, 
police,  training  and  supply  files,  thus  delimiting  access  to 
OHMIS  background  data. 

o  TB  18-100,  Army  Automation  Life  Cycle  Management  -  Prescribes 
the  life  cycle  management  of  Army  ADP  projects.  Directly 
applicable  to  the  next  phase  of  OHMIS  are  the  sections  on: 

Mission  Element  Need  Statement  -  (MENS) 

System  Decision  Paper  -  (SDP) 

Management  Plan  -  (MP) 

o  TB  18-101,  Army  Automation  Planning,  Programming  and 

Evaluation  System  -  Provides  for  the  management  of  financial 
aspects  of  ADP  procurement  and  operation.  As  such  it  is  of 
primary  interest  to  the  project  officer. 

o  TB  18-103,  Software  Design  and  Development  -  The  provisions 
of  this  TB  are  mandatory  for  all  new  software  design  and 
must  be  incorporated  in  any  procurement  document.  The  TB 
provisions  are  too  detailed  to  set  forth  in  a  synopsis  but 
include  ADP  analysis  and  design,  design  techniques,  data 
base  management  systems,  privacy  (AR  340-21)  and  ADP 
security  (AR  380-380).  System  designers  must  be  totally 
familiar  with  the  provisions  of  this  TB. 

o  TB-106,  Deployment,  Operations  and  Termination  of  Automated 
Data  Systems  -  Prescribes  standard  operating  procedures  for 
the  life  cycle  management  of  ADP  systems.  The  milestone 
procedures  for  deployment  of  a  new  system  should  be 
integrated  into  the  FY  86-87  Management  Plan. 

o  TB-109,  Army  Automation  Economic  Analysis  -  Sets  forth 
requirements  and  techniques  for  analysis  of  alternative 
systems.  See  Section  IV  of  this  report  for  the  actual 
analysis  of  OHMIS. 

o  TB-110,  Army  Automation  Configuration  Management  -  Sets 
forth  procedures  for  controlling  the  ADP  hardware  and 
software  throughout  the  life  cycle  of  the  system.  A 
configuration  management  plan,  tailored  to  the  scope  and 
technical  characteristics  of  OHMIS  should  be  developed  in 
conjunction  with  the  initial  programming  effort  and  updated 
as  required  throughout  the  OHMIS  life  cycle. 
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o  TB  18-111,  Army  Automation  Technical  Documentation  - 

Implements  the  documentation  requirements  of  DoD  Standard 
7935.1-5,  and  its  provisions  should  be  incorporated  in  any 
programming  contractual  document. 

o  TB-112,  Training  Management  for  ADP  Systems  -  (Not  yet 
available.) 

o  TB  18-114,  Computer  Performance  Measurement  and  Evaluation  - 
Provides  hardware  and  software  optimization  PME  techniques. 
While  primarily  applicable  to  existing  systems,  its  use 
would  enhance  the  value  of  the  initial  installation  test  and 
evaluation. 

2.2  NEEDS  OF  POTENTIAL  OHMIS  USERS 

The  user  needs  that  must  be  met  in  the  design  of  OHMIS  were  identified 
primarily  during  the  installation  visits  described  in  Section  1.3. 
These  visits  covered  the  local  user  needs.  In  addition,  interviews 
were  held  with  DA  and  HSC  policy  makers  and  management  level  persons 
to  identify  their  needs.  The  OHMIS  needs  expressed  by  the  management 
level  and  their  local  installation  level  potential  OHMIS  users  are 
summarized  below. 

2.2.1  Management  Level  User  Needs 

At  the  senior  management  level  of  the  Army  Occupational  Health  Pro¬ 
gram,  defined  as  the  Office  of  the  Surgeon  General  and  the  Health 
Services  Command  (through  its  operating  arm,  the  U.  S.  Army  Environ¬ 
mental  Hygiene  Agency  (USAEHA),  the  primary  users'  needs  encompass 
that  information  needed  to  plan,  program  and  control  the  system.  In 
terms  of  OHMIS  these  needs  include: 

o  The  ability  to  specify  the  criteria  and  requirements  of  the 
occupational  health  program  and  to  ensure  they  are 
implemented  in  a  timely  manner; 

o  The  ability  to  assess  the  impact  of  new  or  proposed  criteria 
in  terms  of  fiscal  or  manpower  resources.  This  requirement 
dictates  the  ability  to  assess  potential  exposures  to 
regulated  substances  or  processes; 

o  Assess,  specify  and  allocate  personnel  and  fiscal  resources 
based  on  need; 

o  Have  access  to  exposure  data  for  use  in  epidemiological 
studies  and  trend  analyses; 

o  Perform  audit  reports  on  the  performance/workload  of 

selected  installations,  MACOMs  or  on  an  Army-wide  basis; 

o  The  ability  to  compile  and  generate  Army-wide  reports  on 
specific  activities  as  well  as  occupational  illnesses; 


o  The  ability  to  track  the  status  of  abatement  actions  so  as 
to  monitor  performance  and  develop  budget  inputs. 

Meeting  these  centralized  needs  will  be  an  inherent  facet  of  OHMIS 
because  of  the  proposed  centralization  of  OHMIS  data  and  the  ability 
to  access,  compile  and  analyze  data  from  the  five  VIABLE  Regional  Data 
Centers  and  the  HSC  Computer  Center  (probably  the  center  at  Ft. 
Detrick;  possibly  the  Center  at  Ft.  Sam  Houston). 

2.2.2  Local  Installation  Level  User  Needs 

This  Section  discusses  the  needs  expressed  by  the  primary  and  indirect 
users  of  OHMIS  as  identified  during  the  visits  to  the  five  installa¬ 
tions.  These  users  include:  Occupational  Health  Nurses  and 
Physicians,  Industrial  Hygienists,  Radiation  Protection  Officers, 
Hearing  Conservation  Officers,  Safety  Officers  and  Personnel  Officers. 
Their  'needs'  were  typically  expressed  through  suggestions  or  'wish 
lists'  covering  capabilities  for  consideration  as  functions  of  the 
proposed  OHMIS.  In  many  instances,  these  suggestions  simply  involved 
proposed  solutions  to  existing  problems. 

o  Needs  Expressed  by  the  Occupational  Health  Nurses  and 

Physicians: 

1)  Better  interaction/interface  with  Safety  and  Industrial 
Hygiene  in  terms  of  shared  information; 

2)  Ability  to  ensure  that  all  persons  requiring  and/or  needing 
medical  surveillance  are  identified  and  serviced; 

3)  Better  definitions  of  who  should  be  included  in  medical 
surveillance  (e.g.,  those  persons  exposed  versus  those 
persons  in  occupations  believed  to  be  exposed); 

4)  Better  methods  of  identifying  the  hazards  to  which  each 
individual  is  being  and  has  been  exposed; 

5)  Ability  to  easily  (automatically)  analyze  and  correlate 
symptoms  to  exposures; 

6)  Better  guidelines  for  determining  whether  individuals  are 
fit  for  duty  (i.e.,  more  information  on  local  requirements 
within  job  class); 

7)  More  comprehensive  testing  for  fitness  for  duty,  e.g., 
stress  testing,  ergonomic  testing,  etc.; 

8)  Method  of  identifying  and  tracing  former  employees  who  were 
exposed  to  substances/processes  which  have  only  been 
recently  identified  as  being  health  hazards; 
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9)  Involvement  in  the  return  to  work  processing  for  employees 
who  were  injured/ ill ; 

10)  Continuing  health  services  education. 

o  Needs  Expressed  by  the  Hearing  Conversation  Officers: 

1)  Better  interaction/interface  with  Industrial  Hygiene  and 
Safety  with  regard  to  the  identification  of  noise  hazardous 
areas ; 

2)  Ability  to  perform  analyses  of  and  correlations  of  trends  in 
audiometric  test  results  for  any  previous  data,  not  just 
reference/base  line; 

3)  Local  use  of  computerized  data. 

o  Needs  Expressed  by  the  Radiation  Protection  Officers: 

1)  Method  of  ensuring  that  all  persons  who  are  exposed  to 
sources  of  radiation  are  included  in  the  radiation  dosimetry 
program; 

2)  Better  inprocessing/outprocessing  procedures  to  ensure  that 
previous  exposure  records  are  received  and  current  records 
are  forwarded; 

3)  Better  response  time  on  dosimetry  readings.  (Currently  the 
response  time  is  2  to  3  months,  which  has  the  potential 
problem  of  allowing  persons  to  become  or  near  overexposure 
levels,  before  the  need  for  preventive  actions  can  be 
identified. ) 

o  Needs  Expressed  by  the  Industrial  Hygienists: 

1)  Better  interaction  with  Occupational  Health  and  Safety  with 
regard  to  shared  information; 

2)  Method  of  maintaining  up-to-date  hazards  inventories; 

3)  Local  access  to  LOHHI  data; 

4)  Involvement  in  the  selection  of  personal  protective 
equipment; 

5)  Involvement  in  the  design  review  of  building  modifications 
and  construction; 

6)  Involvement  in  the  assignment  of  Risk  Assessment  Codes  for 
deficiencies. 
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o  Needs  Expressed  by  the  Safety  Officers; 

1)  Comparative  analysis  of  injury/illness  experience  between 
installations  of  similar  and  different  operational 
characteristics; 

2)  Ability  to  share  knowledge  between  installations  related  to 
corrective  actions  and  their  effectiveness. 

o  Needs  Expressed  by  the  Personnel  Officers: 

1)  Method  of  analyzing/correlating  excessive  sick  leave  trends; 

2)  More  detailed  hiring  criteria  for  local  job  descriptions 
including  personal  capabilities  and  building  characteristics 
(for  access  by  disabled  persons); 

3)  More  systematic  and  more  automated  method  of  processing 
workers'  compensation  data. 

2.3  PROBLEMS  AND  FEATURES  OF  CURRENT  ARMY  SYSTEMS 


This  Section  reviews  the  current  Army  systems  (both  DA-wide  and  local) 
which  are  related  to  the  implementation  of  the  proposed  OHMIS.  The 
major  features  and  weaknesses  are  described.  This  information  was 
used  to  identify  some  of  the  needed  characteristics  of  the  new  OHMIS. 

Army-Wide  Systems 

o  LOHHI 

Background  information  on  the  LOHHI  projects  is  presented  in 
Section  1.1.1  of  this  report. 

Significant  drawbacks  of  the  LOHHI  systems,  as  currently 
implemented,  relate  to  the  initial  concept  of  the  system  as 
a  "one-shot"  data  collection  effort  to  determine  the  numbers 
of  people  exposed  to  hazardous  materials  and  the  types  of 
materials  to  which  they  were  exposed.  This  concept  has  a 
weakness  as  an  ongoing  system  because  maintaining  current 
data  depends  on  the  ability  of  the  local  installations  to 
perform  detailed  surveys  regularly.  This  was  found  to  not 
be  achievable  at  all  of  the  installations  visited.  The 
cycle  for  LOHHI  surveys  was  approximately  every  three  years 
in  the  installations  visited;  three-year-old  hazards 
information  may  have  some  value  as  a  one-time  measure  of  the 
type  and  degree  of  hazardous  exposures  in  the  DA,  but  it  is 
of  questionable  value  in  the  management  of  an  occupational 
health  program.  LOHHI  II  has  broadened  the  objectives  of 
LOHHI  by  including  the  identification  of  the  individuals 
exposed  to  hazards,  in  addition  to  the  numbers  of  persons 
exposed  collected  in  LOHHI  I.  This  more  detailed  data  has 
not  resolved  the  problem  of  outdated  data;  in  fact,  the 
value  of  noncurrent  data  on  individuals  is  perhaps  even  more 
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questionable  than  outdated  hazards  information  alone.  What 
is  needed  is  a  method  for  identifying  potential  changes  in 
hazardous  exposures  and  a  process  by  which  investigation  of 
these  changes  is  triggered.  This  would  mean  that  DA  hazards 
data  would  not  depend  on  the  periodic  surveys,  but  would  be 
continually  and  incremental ly  (i.e.,  only  selected  items 
of  data)  updated.  Such  a  system  would  require  organizing 
the  hazards  data  base  in  such  a  way  that  a  series  of  data 
elements  on  an  individual  (employee,  facility,  hazard) 
could  be  collected  and  stored  at  different  intervals  than 
the  data  collected  for  other  individuals.  The  core  data 
processing  in  the  OHMIS  recommended  system  design  provides 
for  these  features. 

Another  major  weakness  of  the  system  as  currently 
implemented  is  the  inability  to  manipulate,  at  any  level, 
the  data  which  is  collected  (only  dumps  of  the  data  are 
available).  Yet  a  third  weakness  is  the  lack  of  access  and 
ability  to  utilize  the  LOHHI  data  at  the  local  installation 
level.  Direct  access  to  the  LOHHI  data  for  their  OHMIS 
service  area  by  local  users  and  the  ability  to  generate 
outputs  based  on  user  specified  queries  are  recommended 
features  of  OHMIS. 

o  HEARS 


Background  information  on  the  HEARS  project  is  also 
presented  in  Section  1.1.1  of  this  report. 

The  HEARS  system  seems  to  have  an  exceptionally  high 
compliance  rate  (almost  100%  compliance  in  most  of  the  five 
installations  visited).  This  strong  foothold  is  said  to  be 
a  result  of  the  management  level  emphasis  on  the  program, 
which  is  due  to  the  estimated  $1  million  in  hearing  loss 
claims  per  year  to  the  DA. 

However,  there  are  weaknesses  in  the  system,  as  described 
during  the  interviews  with  the  Hearing  Conservation  Officers 
at  each  installation.  The  most  significant  weakness  is  the 
inaccessibility  of  the  HEARS  data  on  the  local  level. 

Another  problem  noted  is  the  lack  of  reference/baseline 
measurements  on  many  of  the  records.  This  lessens  the 
ability  to  perform  meaningful  trend  analyses  of  threshold 
shifts.  It  was  also  noted  that  the  data  collection  form  for 
the  hearing  tests  required  15-20  minutes  to  complete  while 
the  test  itself  usually  took  half  as  much  time. 

o  Radiation  Protection  Program 

The  Radiation  Protection  Program  within  the  Army  maintains 
the  radiation  exposure  records  and  the  film  badge  program 
for  those  individuals  incurring  exposure  to  ionizing 
radiation.  These  exposure  records  detail  the  amounts  of 
radiation  exposure  each  individual  has  received  during  a 
specified  time  period.  These  records  are  generated  as  a 
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result  of  the  film  badge  program  which  involves  the  issuance 
of  dosimetry  badges  to  measure  the  amount  of  radiation 
received.  The  amount  of  radiation  received  during  the  time 
period  as  well  as  the  cumulative  amount  are  monitored  to 
ensure  that  no  individual  receives  an  overexposure. 

One  major  problem  with  the  radiation  safety  program  as  noted 
by  the  Radiation  Protection  Officers  includes  the  delay 
incurred  for  the  film  badges  to  be  processed  (sometimes  2  to 
3  months).  Excessive  delays  in  the  processing  of  the 
exposure  measurement  could  lead  to  an  overexposure  that  may 
have  been  avoidable  if  current  cumulative  measurements  were 
available.  Another  significant  problem  noted  is  with  the 
in/outprocess ing  procedures.  Many  (estimated  to  be  as  high 
as  90%)  of  the  individuals  within  the  radiation  protection 
program  fail  to  obtain  copies  of  their  previous  exposure 
records  or  neglect  to  collect  their  current  records  prior  to 
transfers.  This  results  in  excessive  paperwork  for  the 
Radiation  Protection  Officer  in  obtaining  previous  records 
and  forwarding  current  records.  Direct  access  to  the  data 
by  authorized  personnel  at  the  local  level,  a  local  user 
query  system  for  this  data,  and  replacing  manual  transfer  of 
records  with  an  automated  system  in  which  the  RSO  can 
retrieve  an  exposure  history  on  an  individual  at  any  time 
and  from  any  location  are  features  that  should  be  included 
in  the  new  OHMIS  system  design. 

Local/Installation  Unique  System 

o  WH ICS  (Work  Hazard  Identification  Control  System) 


The  WH IC  System  is  operated  by  the  Safety  Office  of  the 
Chemical  Systems  Lab  at  the  Edgewood  Area  of  Aberdeen 
Proving  Grounds.  The  system  is  used  to  maintain  records  on 
work  related  exposures  (both  stress  and  chemical)  to  an 
individual .  These  records  are  completed  quarterly 
(updates  are  meant  to  be  submitted  as  they  occur)  by  each 
individual  and  reviewed/verified  by  the  administrative 
person  responsible  for  the  individual.  The  records  are  then 
processed  and  available  for  review  by  the  Occupational 
Health  Nurses  and  Physicians.  The  Occupational  Health 
Nurses  and  Physicians  use  the  exposure  data  to  determine  the 
content  of  the  medical  surveillance  examinations  performed 
on  a  given  individual  as  well  as  to  help  identify  those 
individuals  requiring  medical  surveillance. 

While  WHICS  has  many  outstanding  features,  there  are  some 
significant  problems  with  its  current  operation.  One 
particular  problem  includes  the  lack  of  any  historical  data 
on  exposures  to  individuals  (not  even  a  hard  copy). 

Possibly  the  most  significant  problem  with  WHICS  is  the 
pending  responsibility  issues.  During  a  manpower  survey, 
the  operation  of  WHICS  was  determined  to  be  a  medical  rather 
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than  a  safety  function  and  the  Safety  Office  of  the 
Chemical  Systems  Lab  was  required  to  relinquish  operation  of 
the  system  to  the  local  Medical  Activity. 

Occupational  Environmental/Health  System  (OE/HS) 

During  the  visit  to  Walter  Reed  Army  Medical  Center  (WRAMC), 
the  Occupational  Environmental/Health  System  was  reviewed. 
This  system  is  in  the  implementation  phase  and  will  be  used 
to  generate  notices  to  individuals  of  the  periodic  medical 
exams  that  are  due;  notices  to  supervisors  identifying  their 
employees  requiring  medical  exams;  and,  a  Control  Register/ 
Schedule  for  use  by  the  Occupational  Health  Clinic.  Each  of 
the  outputs  from  the  OE/H  System  includes  the  test  require¬ 
ments  for  each  individual. 

Patient  Registry  System 

Another  system  identified  during  the  visit  to  WRAMC  was  the 
Patient  Registry  System.  This  system  will  eliminate  the 
need  for  users  to  repeatedly  input  basic  identification  and 
demographic  data  (registration  data)  for  each  patient.  The 
Patient  Registration  System  captures  this  basic  data  in  a 
form  that  can  be  retrieved  and  linked  to  the  next  entry  on 
the  individual,  thus  reducing  the  user  clerical  workload. 

Medical  Record  Tracking  System 

Also  identified  during  the  visit  to  WRAMC  was  the  Medical 
Record  Tracking  System.  This  Record  Tracking  System  (RTS) 
maintains  a  log  of  all  charts  in  circulation.  Circulation 
is  defined  as  the  state  of  any  physical  chart  that  has  been 
checked  out  of  the  Medical  Records  Department.  The  RTS 
allows  qualified  personnel  who  have  access  to  CRTs  to  issue 
requests  for  patient  records  and  to  generate  a  prioritized 
request  in  the  file  room. 

The  RTS  performs  the  following  functions: 

1)  Provides  for  the  user,  on  demand,  the  location  of  any 
patient  chart  whether  checked  out  to  a  location  or 
inside  the  file  room. 

2)  Maintenance  and  creation  of  a  master  Destination/ 
Location  file.  The  Destination/Location  file  is  shared 
with  the  Radiology  Film  Locator  System. 

3)  Recognizes  individual  records  by  Record  Type.  This  is 
done  through  the  use  of  a  record  identifier  defined  by 
the  MTF,  a  two-digit  volume  number,  different  Family 
Menber  Prefixes  (FMPs),  date  of  birth  and  Social 
Security  number.  Tracking  in  the  Radiology  System  is 
performed  in  a  like  manner,  except  the  Insert  Category 
is  tracked  instead  of  Record  Type. 


4)  Provides  daily  list  of  overdue  charts. 

5)  Generates  circulation  statistics. 

6)  Provides  a  purging/retirement  routine. 

7)  Provides  single  and  multiple  pull  lists,  and  the 
ability  to  override  or  delete  requests  after  having 
been  placed. 

These  are  features  worth  considering  in  OHMIS.  However,  the 
feasibility  of  a  medical  record  tracking  system  that  is  only  used  by 
the  Occupational  Health  activity  may  not  be  high. 

2.4  SUMMARY  OF  NEEDED  OHMIS  CAPABILITIES 

In  this  Section,  the  functional  requirements  and  needs  that  must  be 
met  by  OHMIS  are  summarized. 

At  present  there  is  no  existing  overall  ADP  system  to  assist  in  the 
management  of  the  Army  occupational  health  program.  The  establishment 
of  OHMIS  thus  provide  the  Army  with  a  new  capability.  Also,  it  should 
upgrade  the  existing  capabilities  of  LOHHI  and  HEARS.  The  new 
capabilities  provided  by  OHMIS  should  include: 

o  An  ability  to  link  the  hazards  of  a  facility  to  the  medical 
data  of  the  personnel  who  work  in  that  facility.  This  most 
significant  capability  permits  Industrial  Hygiene,  Occupa¬ 
tional  Health  and  line  supervision  personnel  to  work  as  a 
team  in  the  identification  and  correction  of  health  hazards. 

o  Improvements  in  the  areas  of  standardization  and  producti¬ 
vity  following  from  the  institution  of  an  ADP  system  that 
has  outputs  that  can  be  monitored  from  a  central  location. 

o  Improved  ability  to  compare  installations  and  early 
detection  of  trends. 

o  Increased  capability  to  perform  retrospective  epidemio¬ 
logical  studies  through  analysis  of  standardized  archive 
data. 

o  Elimination  of  most  manually  prepared  reports  which  are 
developed  from  numerical  data. 

More  specifically,  OHMIS  should  provide  the  capability  to: 


o  Specify  criteria/requirements  for: 

scheduling  of  medical  surveillance  events 

medical  exams  content 

acceptable  result  levels  from  tests 

job  placement 

scheduling  of  surveys 

survey  content 

acceptable  result  levels  from  sampling 
program  (OH,  IH  and  OHMiS)  performance 

o  Generate  audit  reports  of  performance  (planned  versus  actual 
performance) 

o  Specify  staffing  resources 

o  Generate  medical  exam  schedules  based  on  exam  requirements 
and  staffing  resources 

o  Schedule  referral  lab  work  based  on  exam  results 

o  Generate  notices  regarding  medical  exam  results 

o  Maintain  historical  medical  data  on-line  for  use  in  trend 

analysis 

o  Generate  workers'  compensation  data 

o  Monitor  for  delinquent  medical  exam  appointments 

o  Generate  employee  characteristics  profile  by  facility  for 
use  during  walk-through  surveys 

o  Generate  tabulations  of  occupational  health  and  industrial 
hygiene  services  performed  for  a  specified  time  period 

o  Specify  IH  criteria/requirements  for  survey  content, 
frequency,  sampling  criteria,  results  of  sampling,  and 
hazard  controls  for  those  requirements  unique  to  the 
instal lation 

o  Generate  IH  survey  schedules  based  on  survey  requirements  of 
a  given  faci 1 i ty/organ izat ion/process 

o  Generate  notices  of  scneduled  Iri  surveys  automatically 


2-14 


o  Generate  facility  profiles/worksheets  for  use  during  IH 
surveys 

o  Maintain  current  computerized  data  base  on  facilities/ 
processes/mater ial  and  their  related  hazards  for  trend 
analysis 

o  Recommend  applicable  abatement  actions  for  common  hazards 

o  Record  abatement  actions  by  type  of  hazard,  type  of 
corrective  action  and  RAC  code  priority 

o  Record  and  track  status  of  recommended  abatement  actions 

o  Schedule  periodic/recurring  IH  actions  based  on  frequency 
requ irements 

o  Generate  a  list  of  all  hazardous  materials  procurred  by 
organizations  within  the  installation  for  investigation/ 
survey  as  appropriate 

o  Generate  a  list  of  all  organizations  procurring  a  given 
hazardous  material 

o  Generate  a  list  of  all  facilities  modified  within  the 
installation  and  schedule  applicable  reviews 

o  Generate  a  list  of  all  new  facilities  and  schedule 
applicable  design  reviews 
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SECTION  III  -  INFORMATION  SYSTEM  USERS  AND  USES 


III.  INFORMATION  SYSTEM  USERS  AND  USES 


In  this  Section,  the  needs  identified  in  Section  II  are  summarized  and 
grouped  together  by  the  four  major  types  of  OHMIS  users.  For  each 
OHMIS  user,  the  needs  are  converted  into  uses,  i.e.,  the  ways  in 
which  an  ideal  occupational  health  information  system  would  be  used 
if  it  were  to  meet  all  of  the  user's  needs  for  operating  an  occupa¬ 
tional  health  program.  The  uses  for  each  OHMIS  user  have  been  grouped 
together  into  what  are  called  use  modules  for  quick  identification 
of  similar  uses.  FIGURE  3-1  shows  the  four  types  of  users  and  the  use 
modules  for  each  type  of  user.  The  identification  of  the  use  modules 
for  each  OHMIS  user  form  the  basis  on  which  the  recommended  system 
description  for  OHMIS  was  developed.  In  particular,  it  was  the 
fundamental  underlying  similarity  in  the  data  processing  function  of 
all  of  the  uses  of  an  information  system  in  an  occupational  health 
program,  as  identified  in  these  use  modules  that  led  to  the  formula¬ 
tion  of  the  11  core  OHMIS  data  processing  functions  described  in 
Section  VI. 

3.1  SYSTEM  USERS 


In  the  review  of  user  needs  described  in  Section  II,  it  was  found  that 
the  needs  naturally  grouped  themselves  by  the  type  of  users  of  an 
occupational  health  information  system.  Four  major  types  of  users 
were  identified.  These  are  referred  to  as: 

1)  System  Administrator  User  Group:  This  is  the  management 
level  user  of  an  occupational  health  information  system, 
e.g.,  the  user  at  the  DA  or  Major  Command  level.  The  funda¬ 
mental  roles  of  the  System  Administrator  group  of  OHMIS 
users  will  be  to  develop  and  specify  all  of  the  DA-wide  (or 
command-wide)  operating  requirements  and  criteria  of  thc- 
Department  of  the  Army's  occupational  health  prog,  an:  to 
translate  these  requirements/criteria  into  their  •c'/ica- 
tions  for  the  operation  and  maintenance  of  an  oc  ,  .  .ional 
health  information  system;  to  use  the  OHMIS  systt  io 
monitor  compliance  with  and  evaluate  the  effectiveness/ 
feasibility  of  these  requirements/criteria;  and,  to  take 
actions  to  address  failures  to  comply  with  or  inadequacies 
of  these  requirements/crit^ria,  including  modifications  to 
the  requirements/criteria. 

2)  Occupational  Health  User  Group:  This  group  of  users 
includes  the  Occupational  Health  Physician  and  Occupational 
Health  Nurse  as  well  as  the  entire  array  of  medical 
technicians  and  paraprofessionals  involved  in  providing 
occupational  health  services  to  DA  employees,  both  military 
and  civil ian. 

3)  Industrial  Hygiene  User  Group:  This  group  of  users  refers 
to  tne  entire  array  of  Industrial  Hygienists,  Technicians, 
and  hazard  specialists  (e.g.,  Radiation  Safety  Officers) 
involved  in  the  identification,  monitoring  and  control  of 
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occupational  health  hazards  to  which  DA  employees  are 
exposed. 

4)  Safety  User  Group:  This  group  of  users  is  equivalent  to 
the  Industrial  Hygiene  User  Group,  except  that  these  persons 
primarily  address  occupational  safety,  as  distinguished 
from  occupational  health,  hazards.  This  is  an  optional 
group  of  users  in  the  OHMIS  system  in  that  participation  of 
the  safety  users  in  OHMIS  is  desirable,  but  not  necessary, 
for  its  operation.  The  very  great  similarity  in  many  of 
these  uses  of  an  occupational  health  information  system 
between  the  Industrial  Hygiene  and  Safety  User  Groups 
suggests  that  shared  use  of  the  OHMIS  system  by  these  two 
groups  would  be  beneficial  and  feasible. 

The  uses  of  an  occupational  health  information  system  for  each  of  the 
first  three  of  the  above  OHMIS  users  are  given  below.  For  each  user, 
a  series  of  use  modules  are  identified  (see  FIGURE  3-1)  and  then  the 
specific  uses  covered  under  the  module  are  briefly  reviewed.  In 
describing  the  use  modules,  the  tone  used  is  to  explain  the  major  ways 
in  which  each  user  would  use  OHMIS  if  the  system  were  already  in 
place. 

3.2  SYSTEM  ADMINISTRATOR  USE  MODULES 


The  four  System  Admini strator  use  modules  described  below  cover  the 
management  level  uses  of  OHMIS.  These  include  the  use  of  OHMIS  to 
perform  and  monitor  all  of  the  uses  applicable  to  the  Occupational 
Health  and  Industrial  Hygiene  users.  However,  the  System  Administra¬ 
tors'  use  of  the  system  would  not  be  limited  to  the  boundaries  of  a 
single  installation  as  would  the  local  users.  All  System  Administra¬ 
tor  uses  of  OHMIS  apply  to  the  access,  inquiry,  and  output  of  data 
for : 

1.  a  given  installation; 

2.  a  group  of  installations  or  a  command  (e.g.,  HSC);  or 

3.  all  CONUS  installations. 

Similarly,  the  uses  that  should  be  covered  by  OHMIS  for  System 
Administrators  enable  the  central  definition  of  criteria  and 
performance  requirements  for  the  following: 

o  scheduling  of  medical  surveillance  exams 

o  medical  exam  content 

o  acceptable  results  levels  from  tests 

o  job  placement 

o  scheduling  of  surveys 

o  survey  content 
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o  monitoring  criteria 

o  program  performance  (OH,  IH  and  QHMIS) 

o  report  generation 

The  definition  of  the  criteria  and  performance  requirements  may  apply 
to  a  single  installation,  a  group  of  installations  or  command,  or 
OA-wide.  The  criteria  and  requirements  defined  by  the  System 

Administrators  will  take  precedence  over  the  local  Occupational  Health 
or  Industrial  Hygiene  defined  requirements  and  criteria. 

3.2.1  'System  Controls  and  Criteria  Tables1  Use  Module 

The  System  Controls  and  Criteria  Tables  Use  Module  covers  the  use  of 
OHMIS  by  management  level  users  to  centrally  define  and  maintain  the 
criteria  and  performance  requirements  of  the  system.  This  group  of 
uses  also  includes  defining  of  log-on/password  procedures  for  the 
local  installation  activities. 

This  use  module  also  covers  the  performance  of  an  audit  trail  function 
to  “backtrack"  transactions  in  the  event  of  system  failure. 

OHMIS  USES  COVERED  IN  THE 
'SYSTEM  CONTROLS  AND  CRITERIA  TABLES'  USE  MODULE 

o  Enter  DA  or  installation  specific  criteria  for  allowable 
limits  for  medical  tests  and  monitoring. 

o  Enter  DA  or  installation  specific  requirements  for  medical 
surveillance  activities  and  surveys  (e.g.,  scope,  content 
and  frequency). 

o  Enter  DA  or  installation  specific  job  placement 
requirements . 

o  Enter  authorization  table  data  for  procurement  criteria  for 
hazardous  materials. 

o  Enter  performance  criteria  for  DA  or  installation  specific 
OH  and  IH  activities. 

o  Enter  log-on/password  table  assignments, 

o  Generate  audit  trail. 

3.2.2  'System  Abatement  Action'  Use  Module 

The  System  Abatement  Action  Use  Module  covers  the  review  of  data  on 
deficiencies  cited  during  surveys,  the  assignment  of  risk  assessments 
to  deficiencies  cited,  the  determination  of  possible  abatement 
actions,  and  the  monitoring  of  the  compliance  of  recommended  abatement 
actions.  Once  an  appropriate  abatement  action  has  been  identified  and 
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entered,  the  local  activities  would  need  to  be  notified  in  order  that 
they  may  review  the  applicability  of  the  abatement  action  to  local 
deficiencies.  Generic  abatement  actions  (appropriate  under  all 
conditions)  may  need  to  be  automatical ly  applied  to  deficiency 
records . 

OHMIS  USES  COVEREO  IN  THE 
'SYSTEM  ABATEMENT  ACTION1  USE  MODULE 

o  Enter  recommended  abatement  actions. 

o  Enter  appropriate  risk  assessment  (RAC)  code  and  prioritize 
actions. 

o  Monitor  status  of  abatement  actions. 

o  Generate  status  report  for  all  deficiencies. 

o  Generate  exception  report  of  deficiencies  not  abated  within 
specific  time. 

o  Generate  instal lation/DA-wide  status  of  abatement  require¬ 
ments  by  type  and  cost. 

3.2.3  ‘System  Audit/Evaluation1  Use  Module 

This  use  module  covers  the  need  to  be  able  to  generate  correlations  of 
planned  versus  actual  performance  of  Occupational  Health,  Industrial 
Hygiene  or  overall  OHMIS  activities. 

3.2.4  ‘System  Analysis  and  Report*  Use  Module 

The  System  Analysis  and  Report  Use  Module  covers  the  following  System 
Administrator  uses  of  OHMIS: 

o  Generation  of  ad  hoc  outputs  with  the  report  parameters 

defined  at  the  time  of  request.  The  user  may  also  wish  to 
retain  tiie  outputs  to  allow  routine  generation  at  later 
dates . 

o  Generation  of  correlations  of  medical  surveillance  and 

survey  sampling  results  for  selected  populations  as  a  part 
of  epidemiological  studies. 

o  Generation  of  required  Army  and  DoD  occupational  health 
status  reports. 

3.3  OCCUPATIONAL  HEALTH  USE  MODULES 

The  Occupational  Health  use  modules  described  below  cover  the  follow¬ 
ing  local  uses: 
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o  Schedule  and  monitor  exam  appointments. 

o  Record  medical  exam  and  medical  events  (e.g.,  injuries  and 
illnesses). 

o  Generate  medical  sutmiary  data  (e.g.,  diagnosis,  treatment). 

o  Maintain  current  and  historical  employee  data  pertinent  to 
occupational  health. 

o  Assist  in  the  analysis  of  causal  data,  generate  performance 
reports  and  define  criteria  and  requirements  data. 

3.3.1  ‘Medical  Exams  Scheduling*  Use  Module 

The  Medical  Exams  Scheduling  Use  Module  covers  the  use  by  Occupational 
Health  users  of  resources  data  on  both  medical  staff  and  equipment  and 
the  recording  and  generating  of  appointment  schedules.  Apoointment 
notices  for  medical  surveillance  would  need  to  be  generated  based  on 
the  OH  resources  available  and  the  medical  surveillance  requirements 
attached  to  each  employee.  Referral  appointment  notices  to  other 
clinics  would  also  need  to  be  generated  based  on  the  employees' 
medical  surveillance  requirements.  Notices  of  delinquent  exams  would 
need  to  be  automatically  generated  as  the  suspense  dates  arrive. 

OHMIS  USES  COVERED  IN  THE 
'MEDICAL  EXAMS  SCHEDULING'  USE  MODULE 

o  Enter  available  staffing  and  equipment  resources. 

o  Schedule  appointments. 

o  Enter  modifications  to  schedule. 

o  Generate  appointment  notices  to  organizational  unit, 

supervisor  and  employee. 

o  Generate  delinquency  notices  to  organizational  unit, 

supervisor  and  employee. 

3.3.2  'Medical  Events  Treatment'  Use  Module 

This  use  module  covers  the  recording  of  the  medical  exams  and  events 
data  collected  during  pre -employment  exams,  preplacement  exams, 
medical  surveillance  exams,  injury/illness  events,  etc.  During  entry 
of  the  medical  exams/tests  results,  abnormal  values  would  need  to  be 
flagged.  Unusually  high/low  values  or  significant  shifts  from 
previous  values  should  trigger  a  request  for  retesting  or  analysis. 
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The  user  may  use  OHMIS  to  output  the  medical  events  summary  data  for 
up  to  five  preceding  years  in  order  to  be  able  to  review  the  overall 
medical  surveillance  profile  for  an  individual  or  group  of  individuals 
for  trend  analysis.  Another  use  of  the  OHMIS  system  included  in  this 
module  would  be  to  generate  notices  disseminating  the  results  of  an 
employee's  exam/event.  The  generation  of  activity  performance  reports 
using  the  medical  events  summary  data  for  a  specific  time  period  would 
be  another  use  in  this  group  of  uses. 

OHMIS  USES  COVERED  IN  THE 
'MEDICAL  EVENTS/TREATMENT'  USE  MODULE 


o  Enter  medical  exams/tests  results  data, 
o  Enter  medical  events  suimary  data. 

o  Generate  a  medical  surveillance  profile  for  a  specific  time 
period . 

o  Generate  notices  regarding  exam/event  results. 

o  Generate  exception  report  on  missing  data  (e.g.,  referral 
appointment  test  results). 

o  Generate  tabulations  of  services  performed  for  specific  time 
period . 

3.3.3  'Employee  Characteristics'  Use  Module 

The  Employee  Characteristics  use  module  covers  the  use  of  the  OHMIS 
current  and  historical  data  on  each  employee  receiving  services  from 
the  local  Occupational  Health  activity.  This  data  would  need  to  be 
recorded  and  maintained  by  OHMIS.  Each  accession  of  an  employee 
characteri sties  record  should  prompt  verification  and  updating  of  any 
outdated  or  missing  information. 

The  OHMIS  employee  data  will  be  "loaded"  from  the  SIDPERS,  JUMPS, 

SC  I  PM  I S  and  ST  ARC  IPS  systems  for  background  and  demographic  data. 
Transactions  to  these  external  data  sources  would  need  to  be  extracted 
to  maintain  current  data.  Notices  to  the  proponent  of  these  source 
systems  regarding  incorrect/outdated  information  should  be  transmitted 
via  electronic  mail  when  discrepancies  are  identified  through  medical 
exams/events . 


OHMIS  USES  COVERED  IN  THE 
'EMPLOYEE  CHARACTERISTICS'  USE  MODULE 


o  Enter  employee  characteristics. 

o  Review/ verify/ update  correct  employee  characteristics  data. 

o  Generate  notices  to  source  systems  of  incorrect/outdated 
data  through  electronic  mail  system. 
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o  Generate  notice  to  personnel  office  of  an  individual's 

changed  physical  profile  for  required  personnel  action(s). 

3.3.4  ‘OH  Analysis  and  Report1  Use  Module 

This  use  module  covers  the  local  Occupational  Health  Nurse  group  of 
user's  needs  to  define  and  generate  ad  hoc  reports,  generate  planned 
versus  actual  performance  correlations  and  generate  medical 
surveillance  profiles  for  individuals  or  groups  of  individuals  with 
common  characteristics  or  combinations  of  characteristics  for  use  in 
trend  analysis. 


OHMIS  USES  COVERED  IN  THE 
'OH  ANALYSIS  AND  REPORT’  USE  MODULE 


o  Generate  user  defined  reports. 

o  Generate  correlation  of  predicted  and  actual  performance  of 
OH  activity. 

o  Generate  medical  surveillance  profile  for  an  individual  or  a 
group  of  individuals. 

3.3.5  ‘OH  Controls  and  Criteria  Tables'  Use  Module 

At  the  local  installation  level,  the  Occupational  Health  user  will 
need  to  have  capabilities  similar  to  those  of  the  System  Administrator 
with  regard  to  defining  criteria  and  requirements .  However,  the  local 
Occupational  Health  activity  should  be  allowed  to  define  criteria  and 
performance  requirements  for  its  installation  and  only  those  criteria 
and  requirements  within  the  responsibility  of  the  Occupational  Health 
activity  (with  certain  exceptions  for  those  Occupational  Health 
activities  which  are  also  responsible  for  Industrial  Hygiene  uses  of 
OHMIS). 


OHMIS  USES  COVERED  IN  THE 
'OH  CONTROLS  AND  CRITERIA  TABLES'  USE  MODULE 


o  Enter  installation  unique  allowable  limits  for  clinical 
tests  and  exam  results. 

o  Enter  installation  unique  criteria  for  medical  surveillance 
requirements . 

o  Enter  installation  unique  criteria  for  job  placement 
requirements. 

o  Enter  predicted  service  performance  criteria. 

o  Generate  transaction  audit  trail. 

3.4  INDUSTRIAL  HYGIENE  USE  MODULES 

The  Industrial  Hygiene  user  will  need  to  use  OHMIS  to  record  criteria 
and  requirements  unique  to  the  installation  pertaining  to  staff  and 


3-8 


equipment  resources,  to  specify  survey  content  and  frequency,  to 
specify  action  levels  of  sampling  results,  and  to  generate  survey 
schedules  based  on  these  criteria  and  requirements.  This  type  of  user 
will  alsowish  to  generate  facility  survey  profiles  for  use  in  the 
field  during  surveys  and  to  record  the  survey  data. 

Appropriate  abatement  actions  will  need  to  be  identified  and  related 
to  each  deficiency  cited  during  a  survey.  This  user  will  then  use 
OHMIS  to  monitor  these  suggested  abatement  actions  for  implementation. 

3.4.1  1 IH  Survey  Scheduling'  Use  Module 

This  use  module  covers  the  Industrial  Hygiene  User  Group's  use  of 
OHMIS  to  record  staffing  resources  and  to  schedule  surveys  based  on 
these  resources  and  the  survey  requirements  for  each  facility. 

Another  use  in  this  module  is  the  generation  of  notices  to  the  organi¬ 
zational  units  to  be  surveyed  as  well  as  the  scheduling  for  all 
surveys  planned  for  a  specified  time  period.  Automatic  monitoring  of 
surveys  not  completed  as  suspense  dates  arrive  is  another  OHMIS  use  in 
this  module. 


OHMIS  USES  COVERED  IN  THE 
'IH  SURVEY  SCHEDULING'  USE  MODULE 


o  Enter  staffing  resources, 

o  Generate  survey  schedules, 

o  Enter  modif ications  to  schedule. 

o  Generate  survey  notices  for  organizational  units, 

o  Generate  list  of  delinquent  surveys. 

3.4.2  'IH  Survey'  Use  Module 

This  module  covers  the  use  of  OHMIS  to  record  survey  results.  The 
results  of  a  survey  will  need  to  be  entered  and  used  to  update  the 
OHMIS  facility  data  file.  This  data  would  need  to  be  used  to  generate 
the  facility  survey  profiles  employed  during  the  next  survey  of  that 
f ac i 1 i ty . 

Another  use  covered  by  this  module  is  the  identification  of  a  list  of 
proposed  modifications  to  an  existing  facility.  This  list  would  allow 
the  Industrial  Hygienist  to  contact  the  applicable  organizational  unit 
to  discuss  the  modifications  and  any  potential  health/safety  effects 
which  may  result.  Similarly,  this  user  could  use  a  list  of  new 
facilities  so  that  the  designs  for  such  facilities  may  be  reviewed  for 
possible  health/safety  problems.  These  lists  of  modified  and  new 
facilities  would  need  to  be  generated  via  the  transactions  to  the 
Integrated  Facility  System  (IFS)  (an  external  data  source  that  needs 
to  be  incorporated  into  OHMIS). 
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A  list  of  hazardous  materials  issued  may  also  be  a  use  of  OHMIS 
included  in  this  module.  The  list  would  be  used  to  monitor  which 
organizational  units  are  procuring  hazardous  materials  in  order  that 
the  appropriateness  of  the  use  of  the  materials  and  the  necessary 
controls  can  be  reviewed. 


OHMIS  USES  COVERED  IN  THE 
‘ IH  SURVEY*  USE  MODULE 


o  Enter  survey  results, 

o  Generate  facility  survey  profiles. 

o  Generate  exception  report  of  missing  data  (e.g.,  sampling 
results) . 

o  Generate  list  of  modifications  to  facilities, 

o  Generate  list  of  new  facilities. 

o  Generate  notices  to  source  systems  of  incorrect/outdated 
data  through  electronic  mail. 

o  Generate  list  of  hazardous  materials  issued. 

3.4.3  1 IH  Abatement  Action'  Use  Module 

This  use  module  covers  the  use  of  OHMIS  to  enter  recommended  abatement 
actions  for  each  deficiency  cited  during  a  survey.  Another  use 
included  in  this  module  is  to  record  those  abatement  actions 
implemented  and  to  monitor  the  status  of  all  open  deficiencies. 
Generation  of  notices  of  recommended  abatement  actions  to  responsible 
organizational  units  would  be  another  Industrial  Hygienist  use  of 
OHMIS  covered  in  this  module. 

OHMIS  USES  COVERED  IN  THE 

' IH  ABATEMENT  ACTION*  USE  MODULE 


o  Enter  recommended  abatement  action  for  each  deficiency  cited 
with  the  attendant  Risk  Assessment  (RAC)  code. 

o  Enter  implemented  abatement  action  data. 

o  Generate  notice  to  abate  deficiencies  cited  during  survey  by 
RAC  code  prioritization. 

o  Generate  list  of  all  known  deficiencies  not  abated. 

o  Generate  list  of  all  known  deficiencies  for  which  no 

abatement  action  has  been  identified. 

o  Generate  status  report  for  all  known  deficiencies  by 
installation /organization /facility. 
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3.4.4  * IH  Analysis  and  Report'  Use  Module 


This  use  module  covers  the  need  of  the  Industrial  Hygiene  User  Group 
to  define  and  generate  ad  hoc  reports  as  necessary.  OHMIS  would  also 
need  to  be  used  to  generate  planned  versus  actual  performance 
evaluation  reports  and  reports  correlating  the  medical  surveillance 
results  with  the  sampling  results  for  a  specified  population. 


OHMIS  USES  COVERED  IN  THE 
1 IH  ANALYSIS  AND  REPORT'  USE  MODULE 


o  Generate  use  defined  reports. 

o  Generate  correlation  of  predicted  and  actual  performance  of 
IH  activity. 

o  Generate  correlation  of  medical  profiles  and  survey 
prof i les . 

3.4.5  ‘IH  Controls  and  Criteria  Tables1  Use  Module 

This  use  module  covers  the  use  of  OHMIS  by  the  Industrial  Hygiene 
activity  to  define  criteria  and  requirements  unique  to  the 
installation,  to  prescribe  allowable  limits  pertaining  to  survey 
sampling  results;  to  specify  survey  content  and  frequency;  and  to 
monitor  the  issuing  of  hazardous  materials.  Another  use  included  in 
this  module  is  to  enter  predicted  performance  criteria  in  order  that 
a  planned  versus  actual  performance  evaluation  can  be  made. 

OHMIS  USES  COVERED  IN  THE 
' IH  CONTROLS  AND  CRITERIA  TABLES'  USE  MODULE 


o  Enter  installation  unique  allowable  limits  for  survey 
sampling  results. 

o  Enter  installation  unique  criteria  for  survey  requirements 
( e . g . ,  frequency,  content). 

o  Enter  installation  unique  criteria  for  requirements  to 
monitor  hazardous  materials. 

o  Enter  predicted  service  performance  criteria. 

o  Generate  transaction  audit  trail. 
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IV.  EVALUATION  OF  OPTIONS  FOR  SYSTEM  DESIGN 


In  this  Section,  the  two  basic  options  for  designing  an  occupational 
health  information  system  for  the  Department  of  the  Army  are 
evaluated  and  a  recommended  approach  is  given,  namely,  the  development 
of  a  new  system  for  OHMIS. 

4 . 1  OPTIONS  FOR  SYSTEM  DESIGN 

In  general  terms,  there  are  two  options  for  the  development  of  a 
design  of  an  occupational  health  information  system  for  the  Army: 

(1)  Identify  an  existing  system,  or  one  currently  being 
developed,  and  adapt  it  to  the  needs  of  the  DA;  or, 

(2)  Develop  a  new  system  specifically  designed  to  meet  the  needs 
of  the  DA. 

In  order  to  evaluate  these  two  options,  information  was  collected  on  a 
wide  array  of  existing,  commercially  available  systems.  FIGURE  4-1 
shows  the  systems  reviewed.  Not  all  of  the  systems  shown  in  FIGURE 
4-1  are  viable  options  for  OHMIS.  Some  are  not  entire  systems,  but 
only  components  of  an  occupational  health  information  system.  Others 
were  found  to  have  characteristics  which  obviously  excluded  them  from 
use  as  an  option  for  the  development  of  OHMIS.  Of  the  systems  shown 
on  FIGURE  4-1,  10  systems  were  found  to  be  sufficiently  applicable  and 
complete  to  warrant  further  evaluation  as  an  option  for  the  design  of 
OHMIS.  These  systems  were  reviewed  in  detail  and  their  characteris¬ 
tics  compared.  FIGURE  4-2  shows  a  sumary  of  this  review.  As  can  be 
seen,  the  10  candidate  systems  (the  names  of  which  are  shown  across 
the  top  line  of  the  FIGURE)  are  summarized  and  compared  based  on  9 
attr ibutes : 

o  Components  and  modules 

o  Hardware  and  software  environment 

o  Terminals  used 

o  Languages  used 

o  Types  of  access 

o  Data  entry  features 

o  Data  output  features 

o  Security  features 

o  Cost  and  services  provided 
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FIGURE  4-1 


LIST  OF  COMMERCIALLY  AVAILABLE  SYSTEMS 


VENDOR 

1)  IBM 

2)  IBM 

3)  IBM 

4)  IBM 

5)  Tabers  haw  Occupational 
Medicine  Associates,  P. A. 

6)  Mediscreen  Inc. 

7)  SRI  International 


3) 

JRB  Associates,  Inc. 

9) 

S.  C.  Uohnsun 

&  Son,  Inc. 

10) 

Amoco  Computer 

Serv ices 

Co 

ID 

Audiometer  Corporation 
America 

of 

12) 

Audiometer  Corporation 
Amer i ca 

of 

13) 

HSC  Services, 

Inc. 

14) 

H3C  Services, 

Inc . 

16) 

Mini  Computer 

Sys  terns 

Inc . 

16) 

International 
Serv ices 

Medical 

NAME  OF  SYSTEM 

Industrial  Medical  Support  Systems 
with  IBM 

IBM  -  Voluntary  Health  Screening 
Examination  Program 

IBM  OHMIS  Program 

IBM  Computer  Oriented  Hearing 
Conservation  Program 

Tabershaw  Occupational  Health 
Management  System  ( TOHMS) 

Mediscreen  Health  Systems 

Center  for  Occupational  and 
Environmental  Safety  and  Health 

Occupational  Medical  Director 
Services 

Occupational  Health  Information 
System  (OH IS) 

Hea1  th/Env  ironmental  Mu  ...gement 
System 

Besserman  Vision  Test  System 

Bessennan  Audiometer  and  Data 
Management 

System  -  8 

System  -  7 

Factm  itcher 

METPATH 


i/)  Comprehensive  Management 
aid  nealtn  Care  Systems, 


Community  Mental  Health  Center/ 
Management  Information  Systems 
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LIST  OF  COMMERCIALLY  AVAILABLE  SYSTEMS  (Cont'd.) 


VENDOR 

NAME  OF  SYSTEM 

18) 

Diamond  Shamrock 

Computerized  Occupational  Health 
Environmental  Surveillance  System 
(COHESS) 

19) 

Diamond  Shamrock 

MON  I  TRAC 

20) 

The  Industrial  Health  and 
Hygiene  Group 

BIOTRAK 

21) 

Information  Sciences  Inc. 

InSci  Human  Resources  System 

22) 

Life  Extension  Institute 
(Control  Data  Corporation) 

The  Occupational  Health  Medical 
Survei 1 1 ance  System 

23) 

Flow  General  Inc. 

Flow  GEMINI  (Flow  General's  Medical 
Information  Needs  for  Industry) 

24) 

TRC  Environmental 
Consultants,  Inc. 

Exposure  Record  System  (ERS) 

2b) 

Creative  Socio-Medics  Corp. 

Occupational  Health  Information 
System 

26) 

Creative  Socio-Medics  Corp. 

Creative  Employee  Medical  Informa¬ 
tion  System 

27) 

Comprehensive  Health 
Services,  Inc. 

Rapid  Access  Medical  System  for 
Industry  (RAMS/I) 

28) 

MT  SC 

OMAR 

29) 

Celanese  Corporation 

Celanese  Health  Surveillance 

System 

30)  Mitre  Corporation 
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FIGURE  4-2  (Cont'd.) 
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4.2  EVALUATION  OF  OPTIONS 


TASK  C  of  the  Contract  under  which  this  report  was  developed  (APPENDIX 
A)  required  evaluating  the  options  for  the  development  of  OHMIS  and 
selecting  the  "best"  system.  The  evaluation  of  the  existing  systems 
to  identify  the  best  one  follows  naturally  from  the  comparison  of 
system  characteristics  described  above  and  shown  in  FIGURE  4-2. 
However,  the  comparison  of  the  best  existing  systems,  which  have 
actual  limiting  characteristics,  with  a  new  system  that  has  only 
hypothetical  characteristics  and  can  be  changed  to  fit  the 
evaluation,  is  theoretically  more  difficult  to  do  systematically.  By 
definition,  there  is  always  a  "best"  system  among  the  existing 
options.  However,  when  compared  with  a  new  system  that  has  not  yet 
been  developed  and,  therefore,  is  infinitely  flexible,  the  new  system 
can  always  be  defined  so  that  it  is  the  "best”  system,  regardless  of 
what  system  to  which  it  is  compared.  For  a  similar  reason,  it  is  not 
possible  to  evaluate  a  new,  undeveloped  system  based  on  a  set  of 
evaluation  criteria  because  in  developing  the  description  of  the 
proposed  new  system,  provisions  for  meeting  any  evaluation  criteria 
(except  those  not  possible  under  any  system)  would  necessarily  be 
incorporated  into  the  proposed  system  design.  Moreover,  because  of 
the  resources  required  to  develop  a  system,  it  was  not  rational  to 
approach  the  evaluation  problem  by  proceeding  with  the  development  of 
a  new  system  that  would  later  be  compared  with  the  existing  system; 
the  new  system  design  could  only  be  developed  based  on  the  assumption 
that  the  second  of  the  above  two  options,  that  of  using  a  new  system, 
was  chosen  as  the  option  for  the  OHMIS  system  design.  Finally,  there 
was  the  additional  problem  in  evaluating  existing  systems  that  arose 
from  a  lack  of  information  about  some  of  the  existing  systems  for  the 
characteristics  that  are  important  to  the  DA.  For  these  reasons,  the 
following  approach  was  taken  to  evaluation  of  the  system  design 
options : 

(1)  Identify  a  set  of  system  evaluation  criteria. 

(2)  Compare  the  existing  systems  (but  not  the  new  system)  to 
the  evaluation  criteria  developed  in  (1). 

(3)  Identify  the  generic  advantages/disadvantages  of  using  an 
existing  system  compared  to  developing  a  new  system.  This 
is  necessary  in  order  to  enable  the  comparison  of  an 
actual  existing  system  with  a  hypothetical  new  system. 

(4)  Based  on  the  generic  criteria  identified  in  (3),  identify 
the  criteria  that  will  rule  out  the  option  of  developing  a 
new  system,  thus,  enabling  either:  (1)  the  selection  of  the 
best  existing  system  (if  the  option  of  a  new  system  is 
ruled  out);  or  (2)  the  selection  of  the  new  system  option 
(if  this  option  cannot  be  ruled  out). 

4.2.1  Evaluation  Criteria 

The  following  are  the  6  criteria  used  to  evaluate  the  existing 
commercial  systems  as  options  for  the  design  of  OHMIS: 
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Cost  of  the  system.  A  specification  of  the  Contract  under 
which  this  project  was  conducted  was  that  the  system  chosen 
must  be  within  the  constraints  cf  a  Class  IV  system.  That 
is,  the  system  must  cost  less  than  $3  million. 

Compatibility  of  the  system  to  reside  on  VIABLE  hardware. 

The  selection  of  the  hardware  (ADPE)  for  OHMIS  was 
constrained  by  the  storage  and  processing  requirements  of  an 
Army-wide  system  as  well  as  the  need  to  stay  within  the 
parameters  of  a  Class  IV  system.  The  review  of  potentially 
available  ADPE  at  the  five  surveyed  installations,  HSC  and 
USAEHA  did  not  reveal  an  ADPE  system  which  was:  a) 
generically  available  at  all  installations,  b)  capable  of 
handling  the  large  storage  and  processing  requirements  of 
OHMIS,  and  c)  would  not  require  extensive  telecommunications 
facilities  to  link  with  an  acceptable  mainframe. 

There  is,  however,  currently  under  development  a  system 
which  meets  all  these  needs,  namely,  the  VIABLE  system 
described  in  Section  1.1.1.  This  extensive  DBM  system  will 
be  installed  at  most  Army  installations  to  meet  the  "Base 
Operations"  functions  of  the  Army.  While  much  of  the  VIABLE 
system  information  is  still  closely  held,  discussions  with 
the  VIABLE  project  team  revealed  that  VIABLE  was  capable  of 
meeting  all  OHMIS  needs  and  that  OHMIS  was  an  acceptable 
candidate  system  for  VIABLE.  The  use  of  VIABLE  would  permit 
development  of  a  full-scale  OHMIS  with  the  need  to  only 
purchase  peripheral  equipment  such  as  terminals,  modems  and 
printers.  This  makes  VIABLE  the  only  system  capable  of 
handling  OHMIS  within  the  Class  IV  system  size  constraint. 
Moreover,  as  described  in  Section  1.1.1,  VIABLE  has  many 
features  that  make  it  an  ideal  host  system. 

In  the  Final  Report  Criteria  Meeting  held  on  September  7, 
1982,  the  VIABLE  alternative  was  discussed  and  a  decision 
made  to  proceed  on  the  assumption  that  VIABLE  would  be  the 
ADPE  used. 


The  decision  to  use  VIABLE  as  the  host  system  for  OHMIS 
meant  that  one  of  the  system  evaluation  criteria  was  that 
the  system  had  to  be  capable  of  residing  on  VIABLE. 

On-line  processing  and  retrieval  of  data.  A  frequently 
repeated  complaint  from  almost  all  potential  users  of  OHMIS 
was  the  current  inability  for  the  user  to  retrieve  data 
from  the  DA' s  existing  occupational  health  data  bases  (i.e., 
LOHHI  and  HEARS).  Moreover,  the  need  for  improved 
communication  between  the  various  users  of  OHMIS  was  one  of 
the  most  frequently  cited  needs  for  OHMIS.  In  addition,  the 
quality  control  requirements  of  OHMIS,  especially  for 
entering  employee  data  or  data  in  which  an  employee  is  the 
unit  being  described  (e.g.,  medical  events  data)  are  such 
that  interactive  entry  is  required.  It  is  not  acceptable 
for  users  of  OHMIS  to  enter  data  on  employees  without 


knowing  that  they  have  identified  the  appropriate  employee. 
Because  of  these  reasons,  it  was  determined  that  the  design 
of  OHMIS  should  be  such  that  it  would  support  an  on-line 
user  query  system  for  data  retrieval  and  an  interactive 
checking  and  editing  system  for  data  entry. 

4)  Easy  interface  with  external  sources  of  data. 

Traditionally,  there  are  5  major  types  of  data  in  an 
occupational  health  information  system:  (1)  data  on 
employees;  (2)  data  on  the  workplace;  (3)  data  on  hazardous 
items  to  which  employees  are  exposed;  (4)  data  on  medical 
events  (both  treatments  and  injuries/illnesses  of 
employees);  and,  (5)  data  on  corrective  actions  for 
hazardous  exposures.  With  the  exception  of  the  fifth  type 
of  data,  substantial  portions  of  all  of  these  data  types 
are  already  being  collected  within  the  DA  for  other 
purposes.  Moreover,  much  of  the  data  on  employees, 

fac i  1 i ties  and  supplies  (the  first  3  types  of  data)  and  the 
inpatient  medical  events  data  (data  type  4)  are  already 
being  collected  in  computerized  form.  Because  of  the 
large  number  of  units  in  the  Da  (i.e.,  the  large  number  of 
employees,  facilities  and  supplies  and  the  corresponding 
large  number  of  medical  events  and  corrective  events),  it 
was  deemed  to  be  totally  unacceptable  to  design  an  OHMIS 
system  that  would  require  manual  re-entry  of  these 
substantial  portions  of  the  potential  OHMIS  data  base  that 
are  already  computerized.  Specifically,  the  recommended 
system  must  be  such  that  it  cannot  only  use  an  existing 
source  of  data  as  the  initial  OHMIS  data  base  ( e . g . ,  the 
data  base  on  employees  currently  employed  by  the  DA),  but 
also  must  be  such  that  it  can  be  updated  routinely  using 
data  from  existing  data  sources.  Any  other  approach  would 
make  the  OHMIS  system  duplicative  and  economically 
impractical  to  operate  and,  therefore,  difficult  to  justify. 
Accordingly,  the  capability  of  interfacing  with  existing  DA 
data  bases  (referred  to  as  external  data  sources)  and 
routinely  receiving  new  input  to  the  system  data  from  these 
external  data  bases  was  selected  as  an  evaluation  criteria. 

5)  High  degree  of  flexibility  and  ready  adaptation  to  changes 
in  DA  needs.  Almost  all  aspects  of  the  DA  occupational 
health  program  are  experiencing  a  great  amount  of  change. 
There  are  changes  in  requirements ,  both  regulatory 
requirements  and  user  needs;  changes  in  the  availability  of 
resources;  changes  in  the  understanding  of  what  constitutes 
hazardous  substances  and  the  occupational  relatedness  of 
diseases;  etc.  There  is  also  considerable  local  variation 
in  needs,  resources  and  capabilities.  Because  of  these 
facts,  the  OHMIS  system  must  be  capable  of  extensive  and 
continuing  modifications.  These  modifications  must  be 
possible  without  extensive  additional  programming  and 
without  degrading  the  previously  generated  OHMIS  data  base. 
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6)  Ability  to  enhance  the  program  management,  audit  and 
quality  assurance  functions  of  the  Army's  occupational 
health  program.  As  described  in  Section  V,  an  all 
pervasive  character isti c  of  the  occupational  health  program 
components  identified  during  the  generation  of  the  OHMIS  use 
modules  (Section  III)  is  the  need  to  identify,  trigger, 
monitor  and  adapt  to  changes  in  requirements  and  the  need  to 
assure  a  high  degree  of  accuracy  and  comprehensiveness  in 
complying  with  requ ireinents .  For  example,  the  occupational 
health  program  must  be  able  to  identify  those  persons  that 
need  a  particular  type  of  medical  examination;  trigger  such 
examinations  at  the  appropriate  intervals;  monitor  that  such 
examinations  are  conducted;  identify  changes  in  either  the 
requirements  for  medical  examinations  or  the  persons  to  whom 
they  apply,  as  well  as  identifying  changes  in  the  operating 
methods  (e.g.,  job  assignments)  that  affect  the  compliance 
with  the  requirements ;  and,  assure  that  all  of  the  above  4 
functions  are  accurate  and  comprehens i ve,  i.e.,  that  all 
employees  needing  examinations  are  identified,  that  all 
examinations  are  conducted  and  that  the  examinations  are 
conducted  in  complete  accordance  with  the  requirements. 

This  same  set  of  functional  requirements  applies  to  most  of 
the  other  uses  of  an  occupational  health  program  (as 
described  in  the  use  modules).  Therefore,  to  meet  the 
functional  requirements  of  a  DA  occupational  health  program, 
the  information  system  should  provide  support  for  the 
execution  of  these  requirement  monitoring  and  assurance 
functions . 

The  first  3  of  the  above  criteria  were  given  the  highest  weight.  This 
is  partly  because  these  are  objective  "Yes/No"  criteria,  while  the 
last  3  criteria  are  a  matter  of  degree.  Thus,  the  systems  can  only  be 
generally  evaluated  by  these  last  3  criteria. 

4.2.2  Evaluation  of  Existing  Systems  Using  the  Evaluation  Criteria 

The  10  systems  reviewed  in  FIGURE  4-2  were  evaluated  in  terms  of  the 
above  6  evaluation  criteria.  None  of  the  systems  met  all  6  criteria; 
in  fact,  none  met  even  the  first  3  minimum  criteria: 

o  Cost  of  the  system.  Candidate  systems  1,  2,  3,  4,  5,  6,  7 
and  8  would  all  exceed  the  cost  constraints  of  a  Class  lv 
system. 

o  Compatible  with  VIABLE.  Candidate  systems  2,  4  and  9  r.re 
incompatible  with  VIABLE  hardware. 

o  On-line  entry  and  retrieval.  Candidate  systems  1,  3,  5,  7 
and  10  are  exclusively  or  primarily  batch  processing  and 
retrieval  systems. 

0  Interface  with  external  data  sources.  None  of  the 

descriptions  of  the  existing  commercial  systems  specifically 
stated  that  the  system  was  designed  to  be  compatible  with 
initial  loading  or  ongoing  input  from  existing  data  bases. 
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Flexibility  and  adaptability  to  continuing  changes.  None 
of  the  system  descriptions  indicated  that  any  system  was 
specifically  designed  to  meet  this  criteria.  However,  some 
of  the  systems  did  provide  for  easy  changes  in  the  operating 
values  of  the  system.  For  example,  the  ability  to  change 
the  values  in  the  unacceptable  values  tables  was  included  in 
some  systems. 

o  Requirements  monitoring  an  assurance.  None  of  the  system 
descriptions  specifically  address  this  concept.  Although 
several  of  the  systems  were  designed  to  identify  the  entry 
of  values  that  were  above  or  below  an  acceptable  value  from 
a  table  that  could  be  generated  by  the  user,  in  no  case  was 
this  process  directly  linked  to  triggering  a  requirement 
(i.e.,  identifying  the  specific  actions  that  should  be  taken 
whenever  the  acceptable  value  is  entered  and  scheduling 
these  actions)  or  to  monitoring  the  completion  of  the 
required  actions  (e.g.,  through  a  reminder  notice  or  status 
report  system). 

In  surrmary,  the  review  of  existing  commercial  systems  for  the 
evaluation  criteria  did  not  result  in  the  identification  of  a  system 
that  stood  out  as  being  obviously  well-suited  for  OHMIS.  No  system 
was  found  to  be  very  close  to  meeting  the  evaluation  criteria,  nor  was 
a  system  found  to  be  capable  of  meeting  almost  all  of  the  user  needs 
specified  for  OHMIS. 

4.2.3  Comparison  of  Generic  Advantaqes/Disadvantaqes  of  an  Existing 
_ System  Versus  a  New  System 

Because  none  of  the  existing  commercial  systems  stood  out  as  being 
obviously  well  suited  for  OHMIS,  the  concept  of  developing  a  new 
system  was  tatni ned .  For  the  reasons  mentioned  above,  it  was  not 
possible  ,  evaluate  the  new  system  in  the  same  way  as  existing 
systems,  instead,  the  approach  was  to  examine  and  compare  the 
generic  advantages  and  disadvantages  of  using  any  existing  system 
versus  any  new  system.  The  aim  was  to  identify  criteria  that  would 
enable  either  one  of  these  two  major  options  to  be  ruled  out.  If  this 
can  be  done,  tnen  the  choice  of  which  system  to  select  (i.e.,  either 
the  best  of  the  existing  systems  or  the  new  system)  would  be  clear. 

Viewing  tne  two  options  (existing  system  versus  new  system)  in  this 
generic  way,  it  can  be  seen  that  the  major  outstanding  advantage  of 
any  new  system  is  that  it  can  be  specifically  designed  to  meet  the 
needs  of  the  user.  In  the  case  of  OHMIS,  the  development  of  a  new 
system  would  mean  that  it  could  be  designed  to  be  compatible  with 
VlABLt,  be  interactive,  interface  with  all  existing  external  data 
sources,  be  flexible,  and  provide  for  requirements  monitoring  and 
assurance.  In  addition,  a  newly  developed  Of, MIS  can  be  designed  to 
perform  each  of  the  use  modules  identified  in  Section  III.  Regardless 
of  tne  features  of  any  existing  system,  a  system  would  never  be 
found  to  be  more  directly  applicable  to  the  user  needs  and  functional 
requirements  of  a  system,  or  more  compatible  with  existing  data 
sources,  procedures  and  programs  than  a  new  system  specifically 
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designed  to  have  these  features.  In  sunmary,  the  outstanding 
advantage  of  any  new  system  is  that  the  designer  can  design  the  system 
to  "get  exactly  what  he/she  wants." 

The  above  generic  advantage  of  any  new  system  is  very  significant  and 
may,  at  first,  appear  to  be  inherently  overriding.  Thinking  in  terms 
of  a  "rule  out"  type  of  criteria,  one  might  ask:  "If  a  new  system  can 
result  in  an  0HM1S  with  the  exact  features  desired,  what  would  be  the 
reason  why  the  new  system  option  would  not  be  chosen?"  The  answer  is, 
of  course,  costs  and  uncertainty.  The  one  limitation  on  the 
outstanding  advantage  of  a  new  system  is  that  the  new  system  can  be 
designed  to  be  an  exact  match  to  the  user's  needs,  provided  costs  are 
not  a  consideration.  More  specif ical ly,  the  two  generic 
disadvantages  of  any  new  system  are:  (1)  the  user  must  pay  the  costs 
to  develop  the  system  and  these  costs  may  be  substantial,  while  there 
are  no  developmental  costs  for  an  existing  system;  and,  (2)  the 
uncertainty  of  the  success  of  a  new  system  as  compared  to  the  knuwn 
degree  of  success  of  any  existing  system.  This  second  disadvantage  is 
related  to  the  first  in  that  the  developmental  costs  of  a  new  system 
that  are  nor  included  in  the  implementation  of  an  existing  system,  can 
be  considered  to  include  those  costs  to  test  and  modify  the  new  system 
to  the  point  where  it  is  operating  successfully. 

Tne  combination  of  the  above  identified  advantages/disadvantages  of  a 
new  system  yields  the  following  conclusion  about  which  option  for  the 
development  for  OHMIS  should  be  chosen.  Because  the  new  system  option 
provides  for  a  system  that  exactly  meets  the  needs  for  OHMIS,  the  new 
system  option  should  be  selected,  unless  it  can  be  shown  that  the 
extra  costs  to  develop  the  new  system  are  either  (1)  beyond  the  limits 
allowed  ( i . e . ,  beyond  the  constraints  of  a  Class  IV  system)  or  (2)  too 
extensive  compared  to  the  extra  user  needs  provided  by  the  new  system 
as  compared  to  an  existing  system.  Put  in  the  opposite  way,  it  would 
clearly  be  better  to  use  an  existing  system  if  it  could  be  found  that 

it  met  all  or  nearly  all  of  the  user  needs  and  evaluation  criteria  and 

was  under  the  allowable  costs,  because  the  uncertainty  of  undertaking 
a  new  system  is  removed. 

As  indicated  above,  only  two  of  the  existing  systems  were  found  _o  be 
under  the  allowable  costs  and  none  of  the  systems  were  found  to  meet 
all  of  tiie  evaluation  cr’teria.  Moreover,  an  examination  of  the  costs 
for  the  recommended  system  design  for  the  new  OHMIS  (given  in  Section 
VIII)  indicates  that  the  costs  are  within  the  constraints  of  a  Class 
IV  system.  Therefore,  a  new  system  cannot  be  ruled  out  an  1  tne 
conclusion  is  that  a  new  system  is  the  "best"  system  for  the 

Department  of  tne  Army's  occupational  health  information  system. 

AECUMMENDED  SYSTEM  D" SIGN 

The  tentative  decision  that  a  new  system  is  the  best  approach  for  ti.e 
design  of  a  DA  occupational  health  information  system  led  to 
development  of  a  recr, nmn  ded  system  design  for  the  new  OHMIS  syst  . 

This  recommended  system  design  is  described  in  the  followinu  4 
sections  of  this  report.  First,  an  overview  of  the  new  sy.t • 
given  (Part  1).  This  is  f  o  1 1  owed  by  the  detail'd  » jnct  i  •>:  ,  •  o  • 
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flows  for  the  11  core  data  processing  functions  of  the  recommended 
OHMIS  system  design  (Part  2).  Next,  the  system  specifications  for  the 
new  recommended  system  are  reviewed  (Part  3).  Finally,  the  expected 
costs  and  impact  of  the  new  system  are  detailed  (Part  4). 


SECTION  V 


-  RECOMMENDED  SYSTEM  DESIGN  -  PART  1 


Summary 


V.  RECOMMENDED  SYSTEM  DESIGN  -  PART  1 
Summary 


This  Section  of  the  report  is  the  first  of  the  4  sections  describing 
the  recommended  system  design  for  OHMIS.  In  this  Section,  a  summary 
of  the  recommended  system  design  is  given. 

5.1  DESIGN  CRITERIA  AND  APPROACH 

Following  the  review  of  existing  occupational  health  information 
systems  in  which  it  was  tentatively  decided  that  the  best  option  for 
the  design  of  OHMIS  would  be  to  develop  a  new  system  description,  a 
description  of  what  the  exact  nature  of  the  new  system  should  be  was 
begun.  In  developing  this  recommended  system  design,  2  major  design 
criteria  were  followed: 

1)  The  recommended  system  design  should  meet  all  of  the  6 
evaluation  criteria  used  in  the  evaluation  of  existing 
systems,  namely,  the  system  should  be: 

Within  the  constraints  of  Class  IV  system 

Capable  of  residing  on  VIABLE 

Interactive 

Capable  of  interfacing  with  existing  external  data 
sources 

Flexible  and  easily  changed 

Capable  of  requirements  monitoring  and  assurance 

2)  The  system  should  enable  the  performance  of  each  of  the  uses 
of  OHMIS  described  in  the  use  modules  given  in  Section  III, 
namely,  the  system  should  provide  a  means  for: 

Identifying  the  DA  requirements  and  criteria  for  an 
occupational  health  program  and  incorporating  these 
requirements/criteria  into  the  information  system's 
decision  making  functions 

Scheduling  and  conducting  medical  exams  and  industrial 
hygiene  surveys  in  accordance  with  DA  requirements 

Identifying  the  abatement  actions  and  follow-up  medical 
services  that  should  arise  from  the  result  of  the 
industrial  hygiene  surveys  and  medical  examinations 

Monitoring  the  abatement  actions  and  medical  services 
to  insure  that  they  are  provided  in  accordance  with  DA 
occupational  health  program  policies  and  procedures 
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-  Generating  suimiary  reports  of  all  data  entered  into 
OHMIS,  including  status  reports  on  compliance  with  the 
occupational  health  program  requirements 

Because  of  the  specifications  given  in  the  contract,  the  approach 
taken  toward  developing  the  recommended  system  design  with  the  above 
features  was  to  provide  a  design  in  sufficient  detail  that  it  is 
suitable  for  programming.  For  this  reason,  the  emphasis  in  the  system 
design  description  given  in  this  report  is  on  the  data  processing 
functions  of  the  occupational  health  information  system,  rather 
than  on  the  programmatic  functions  associated  with  operating  an 
occupational  health  program!  For  example,  the  scheduling  of  medical 
exams  can  be  described  in  terms  of: 


o 


o 


The  input,  processing  and  output  of  the  specific  data 
elements  needed  to  schedule  a  medical  examination,  i.e.. 


data  processing  functions;  or. 


the 


How  the  programmatic  decisions  associated  with  scheduling 
medical  exams  are  made,  i.e.,  the  programmatic  functions. 
Such  programmatic  decisions  would  include:  Who  should 
receive  the  examination;  how  often  should  the  examination  be 
conducted;  what  should  be  the  contents  of  the  examination; 
what  should  be  the  response  to  the  results  of  the 
examination;  who  was  responsible  for  insuring  that  these 
decisions  are  made  and  followed;  and  how  is  the 
responsibility  for  the  decision-making  process  structured, 
e.g.,  how  is  authority  designated. 


Both  the  data  processing  and  the  programmatic  functions  are  needed 
to  operate  an  occupational  health  program  and  to  supply  the  actual 
content  of  an  occupational  health  information  system.  However,  this 
report  is  confined  to  the  data  processing  functions.  This  approach 
was  taken  primarily  because  of  the  constraint  of  providing  a  system 
description  in  sufficient  detail  for  programming,  but  also  because: 


o  Many  of  the  programmatic  functions  are  based  on  policy 

decisions  about  the  operation  of  the  DA  occupational  health 
program.  Although  many  recommendations  for  the  content  of 
these  policies  were  obtained  during  the  study  conducted  in 
preparation  for  this  report,  the  final  decision  about 
program  operation  policy  decisions  are  not  within  the  scope 
of  this  report. 


o  It  was  desired  to  develop  an  occupational  health  information 
system  design  that  was  to  the  greatest  degree  possible 
independent  of  the  specific  programmatic  policy 
decisions  of  the  DA  occupational  health  program.  That  is, 
OHMIS  should  be  capable  of  providing  the  data  processing 
support  for  any  of  the  occupational  health  program 
policies  specified  by  the  DA,  rather  than  being  designed  to 
support  a  specific  set  of  policy  decisions.  This  approach 
was  taken  in  order  to  make  the  information  system  highly 
flexible  and  adaptable  to  change  and  to  ensure  that  the 
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system  was  applicable  to  users  at  a  wide  variety  of 
management  levels  at  which  this  specific  program  policies 
may  vary.  For  example,  it  was  not  deemed  desirable  to 
build  into  the  information  system  any  particular  set  of 
decisions  about  who  should  receive  medical  examinations,  but 
rather  to  design  a  system  that  would  perform  the  data 
processing  functions  for  executing  any  decision  about 
examination  scheduling. 

This  approach  means  that  the  recommended  system  design  is 
necessarily  generic  in  nature.  For  example,  no  specific 
input  forms  are  described  here;  rather,  the  types  of 
inputs  needed  for  the  system's  operation  and  the  data 
processing  functions  for  an,y  OHMIS  form  are  described. 

This  approach  also  means  that  the  development  of  the  OHMIS 
recommended  system  design  was  centered  primarily  around 
identifying  the  types  of  decisions  for  which  the  OHMIS 
computer  program  should  be  capable  of  providing  information 
support. 

Another  closely  related  factor  affecting  the  approach  used  to  design 
OHMIS  was  that  it  should  be  designed  to  be  truly  a  management  tool. 

The  overall  objective  in  the  design  of  OHMIS  is  to  develop  a  system 
that  is  more  than  merely  a  repository  of  the  5  types  of  data  in  an 
occupational  health  system  (employees,  workplaces,  hazards,  medical 
events  and  corrective  action).  While  the  storage  of  these  data 
elements  is  a  requirement  fulfilled  by  OHMIS  and  the  analysis  of 
trends  in  these  data  elements  a  potential  use  for  OHMIS,  it  was 
desired  to  design  OHMIS  to  also  have  a  more  immediate,  practical  use 
that  was  directly  linked  to  improving  the  occupational  health  of  DA 
employees.  Specifically,  OHMIS  has  been  designed  to  provide  support 
to  the  day-to-day  decision-making  processes  involved  in  the 
operation  of  an  occupational  health  program.  Put  another  way,  the 
OHMIS  recommended  system  design  described  in  this  report  covers  the 
data  processing  functions  needed  to  support  the  programmatic 
functions  of  an  occupational  health  program. 

As  will  be  seen,  the  recommended  system  design  of  OHMIS  is  such  that 
the  specific  programmatic  policy  decisions  (requirements)  about  the 
operation  of  the  DA  occupational  health  program  are  first  entered  into 
the  OHMIS  data  base.  The  generic  nature  of  the  design  of  OHMIS  is 
such  that  regardless  of  what  the  specific  requirements  are  entered, 
OHMIS  will  identify  when  the  requirement  is  applicable,  identify  the 
actions  that  need  to  be  taken  to  comply  with  the  requirement  and 
schedule  and  monitor  the  tasks  needed  to  execute  these  actions.  For 
this  reason,  before  OHMIS  can  become  operational,  an  initial  set  of 
occupational  health  program  requirements  must  be  “loaded"  into  the 
OHMIS  data  base.  Although  many  of  these  requirements  are  known, 
large  gaps  in  the  written  prescriptions  provided  for  the  operating 
procedures  of  the  DA  occupational  health  program  were  found  during  the 
installation  visits  made  as  a  part  of  the  study  under  which  OHMIS  was 
developed.  It  was  also  found  that  there  is  an  extremely  wide 
variation  in  the  interpretation  and  implementation  of  those 
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occupational  health  program  policy  decisions  that  are  available  in 
written  form. 


f 


In  light  of  the  current  absence  of  the  information  system  needed  to 
support  the  promulgation  and  Implementation  of  occupational  health 
program  requirements,  the  current  gaps  in  the  Department  of  the  Army's 
occupational  health  program  requirements  should  not  be  considered  to 
be  surprising.  The  institution  of  OHMIS,  as  designed  in  the 
recommended  system  description,  w<ll  greatly  facilitate  the  execution 
of  a  comprehensive,  consistently  administered  occupational  health 
program.  However,  a  prerequisite  step  to  the  implementation  of  OHMIS 
is  the  compilation  of  the  existing  requirement  and  the  identification 
of  an  initial  set  of  additional  DA  occupational  health  program 
operating  requirements.  This  step  Is  referred  to  as  the  development 
of  an  OHMIS  procedural  manual.  As  will  be  seen,  due  to  the 
mechanism  through  which  the  3  types  of  occupational  health  program 
requirements  are  entered  into  the  OHMIS  data  base,  the  procedural 
manual  for  OHMIS  will  consist  largely  of  a  series  of  input  forms. 
Because  of  the  generic  nature  of  the  core  OHMIS  data  processing 
functions  given  in  this  recommended  system  design,  the  input  forms 
for  OHMIS  do  not  need  to  be  developed  prior  to  the  development  of  the 
OHMIS  computer  programs.  Instead,  the  procedural  manual  can  and 
should  be  developeo  at  approximately  the  same  time  that  the 
programming  for  the  core  data  processing  functions  of  OHMIS  is 
developed.  This  will  enable  immediate  loading  of  the  requirements 
specified  in  the  procedural  manual  into  the  OHMIS  data  base  at  the 
completion  of  the  OHMIS  computer  programs.  To  start  OHMIS,  the 
procedural  manual  does  not  need  to  be  comprehensive.  It  need  only 
prescribe  some  of  the  requirements  for  operating  each  of  the 
components  of  an  occupational  health  program.  The  OHMIS  system  design 
is  such  that  changes  or  additions  to  the  initial  program  requirements 
entered  can  be  made  at  any  time.  The  OHMIS  use  modules  developed  in 
Section  III  provide  an  initial  structure  for  identifying  the 
components  of  an  occupational  health  program  for  which  some  initial 
operating  procedures  and  requirements  are  needed. 

In  summary,  the  approach  taken  to  the  development  of  a  recommended 
system  design  for  OHMIS  was  to  identify  a  system  that  will: 

o  Meet  the  6  overall  evaluation  criteria 

o  Meet  the  needs  of  the  OHMIS  users  as  identified  in  the  OHMIS 
use  modules  given  in  Section  III 

o  Provide  a  management  tool  for  the  execution  of  the 

requirements  of  a  DA  occupational  health  program,  the  major 
components  of  which  are  also  identified  by  the  OHMIS  use 
modules 

5.2  MAJOR  TYPES  OF  DATA  IN  THE  OHMIS  USE  MODULES 


As  indicated  above,  the  OHMIS  use  modules  identified  in  Section  III 
cover  the  expected  ways  in  which  OHMIS  will  be  used  to  perform  each  of 
the  components  of  the  DA  occupational  health  program.  Having 


identified  these  uses  of  OHMIS,  the  next  step  in  the  development  of 
the  OHMIS  recommended  system  design  was  to  determine  what  are  the  data 
processing  functions  implied  for  an  information  system  capable  of 
providing  these  uses  and,  in  particular,  a  system  capable  of  providing 
support  for  the  decision-making  processes  involved  in  these  uses. 

To  identify  the  data  processing  functions  implied  by  the  OHMIS  use 
modules,  a  review  of  the  use  modules/program  components  was  made  to 
identify  common  data  elements.  This  review  revealed  a  striking 
similarity  between  almost  all  of  the  use  modules.  The  specifications 
for  each  of  the  occupational  health  program  components  described  in 
the  use  modules  almost  always  involved  3  major  types  of  data: 

1)  A  set  of  requirements  data  for  the  program  component. 

These  requirements  specify  the  actions  that  are  to  be 
taken  to  perform  the  functions  of  the  occupational  health 
program  component.  Some  requirements  also  specify  the 
content  of  the  required  action.  Often  this  was  done  by 
specifying  the  content  of  the  forms  to  be  used  to  enter  data 
during  the  performance  of  a  required  action.  In  addition, 
some  of  the  requirements  specified  the  timing  of  the 
requirement  or  its  frequency. 

2)  A  set  of  data  on  the  prescribed  requirements  indicators. 

The  requirements  indicators  identify  the  occasions  in  which 
a  particular  type  of  requirement  is  to  be  implemented. 

These  indicators  specify  the  events,  conditions  or 
particular  type  of  information  that  is  to  indicate  that  a 
required  action  needs  to  be  executed.  These  indicators  can 
be  classed  into  3  types.  There  are  indicators  specifying 
that  a  required  action  is  to  take  place;  (1)  on  a  given 
date,  (2)  following  a  given  event,  or  (3)  following  the 
entry  of  an  abnormal  reading  on  a  medical  test  or  survey 
sample,  i.e.,  following  the  entry  of  a  value  exceeding  a 
specified  allowable  limit. 

3)  A  set  of  data  on  the  prescribed  applicability  factors  that 
determine  which  of  the  several  specific  requirements  of  a 
given  type  should  be  implemented.  This  type  of  data  is  used 
to  link  each  value  of  a  specified  applicability  factor  to  a 
specific  content  and/or  frequency  of  a  required  action  of  a 
given  type.  Also,  in  some  instances,  there  are 
applicability  factors  determining  whether  or  not  a 
requirement  of  a  given  type  is  to  be  executed  at  all.  In 
these  cases,  the  applicability  factors  and  values  are  used 
to  qualify  a  particular  requirements  indicator.  That  is,  a 
requirement  may  be  indicated  by  a  given  event  if  and  only  if 
the  characteristics  of  the  unit  involved  in  that  event 
(e.g.,  an  employee,  hazard,  or  facility)  match  a  specified 
set  of  values  for  applicability  factors. 

Examples  of  the  use  of  these  3  types  of  data  in  DA  occupational  health 
program  components  can  be  seen  by  examining  2  major  components:  (1) 
The  medical  examinations  component,  and  the  (2)  industrial  hygiene 
survey  component. 
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The  medical  examination  occupational  health  component  is  described 
in  the  medical  examination  scheduling  use  module  and  the  medical 
events/treatment  use  module.  Examples  of  the  3  major  types  of  data 
for  this  program  component  include: 

1)  A  set  of  requirements  data  for  medical  examination 
activities.  These  requirements  include: 

A  series  of  required  actions  for  conducting  medical 
examinations,  including  actions  such  as  conducting  pre¬ 
employment  physical  examinations,  conducting  hearing 
and  vision  tests,  monitoring  the  exposure  to  ionizing 
radiation,  conducting  periodic  medical  surveillance, 
checking  on  the  use  and  fitting  of  personal  protective 
equipment,  following  up  on  abnormal  medical  exam 
findings,  etc. 

For  many  of  these  actions,  some  or  all  of  the 
content  of  a  required  action,  i.e.,  what  should  be 
included  in  the  required  action,  is  specified  in  the 
medical  examination  program  descriptions.  For  example, 
what  should  be  included  in  a  pre-employment  physical, 
hearing  test,  radiation  monitoring  program,  etc.,  are 
specified.  The  content  of  the  medical  examinations  is 
often  specified  on  a  form  for  entering  data  generated 
during  the  execution  of  an  exam.  For  example,  much  of 
what  should  be  included  in  a  hearing  test  (one  of  the 
requirements  of  the  medical  examination  component)  is 
specified  on  HEARS  hearing  test  forms  (Form  2215  and 
Form  2216). 

For  some  requirements,  the  timing  of  the  required 
action  is  specified.  For  example,  the  requirement  may 
specify  that  hearing  tests  are  to  be  conducted 
annual ly. 

2)  A  series  of  indicators,  identifying  when  the  various  types 
of  medical  examination  requirements  are  to  be  executed.  An 
example  of  each  of  the  3  types  of  indicators  are: 

Periodic  medical  examinations  of  a  given  type  are  to 
take  place  during  each  employee's  birth  month  (dated 
indicator); 

A  preplacement  medical  examination  is  to  take  place 
upon  hiring  each  new  civilian  employee  (event 
indicator);  or, 

A  follow-up  examination  is  to  take  place  whenever  an 
employee's  medical  test  result  for  blood  lead  levels 
exceed  'X'  for  • Y '  periods  of  time  (allowable  limits 
indicator). 

3)  A  series  of  applicability  factors  for  each  type  of 
examination  and  the  corresponding  values  of  these  factors 
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for  each  set  of  specific  content/timing  requirements  for  the 
type  of  examination.  Examples  of  factors  that  typically 
determine  whether  a  particular  type  of  examination  is 
applicable  and,  if  so,  which  particular  content  and/or 
timing  of  the  medical  examination  should  be  considered  to  be 
applicable  are:  age,  job  class,  sex,  personal  habits  (e.g., 
whether  the  person  is  a  smoker  or  uses  birth  control  pills), 
etc.  For  example,  hearing  tests  are  frequently  specified  as 
being  required  only  for  certain  job  classes.  In  these 
cases,  the  employee' s  job  class  is  a  factor  determining 
whether  this  type  of  medical  examination  is  applicable. 
Similarly,  the  specification  may  be  that  all  employees  are 
to  receive  periodic  medical  surveillance,  but  employees  over 
the  age  of  50  are  to  receive  them  more  frequently  or  receive 
a  medical  examination  that  includes  additional  tests.  In 
this  example,  age  is  the  applicability  factor  and  the 
value  of  'greater  than  50*  will  be  used  to  identify  a 
different  frequency  and  content  for  the  periodic  medical 
examination  as  being  applicable  than  the  value  of  'less  than 
50'. 

A  similar  set  of  data  is  presented  in  the  documents  describing  the 
contents  of  the  DA  industrial  hygiene  survey  program,  i.e.,  the 
industrial  hygiene  survey  scheduling  and  survey  use  modules  and  the 
corresponding  industrial  hygiene  abatement  action  use  module: 

1)  The  requirement  specified  for  this  program  component 
includes: 

Required  actions,  including:  conducting  of  an 
industrial  hygiene  survey,  following  up  on  a  complaint 
of  a  hazard,  development  of  corrective  actions  for 
hazards  identified,  following  up  on  corrective  actions 
to  determine  that  they  are  implemented,  evaluating  the 
potential  hazardousness  of  a  modification  in  a  facility 
or  a  new  purchase  (supply  item),  etc. 

Contents  of  the  required  actions,  such  as  the  types 
and  methods  for  taking  environmental  monitoring  test 
samples;  the  specific  corrective  or  preventative 
actions  that  are  required  for  a  given  hazard  (these  can 
be  very  detailed,  such  as  the  specific  ventilation 
requirements  for  a  given  amount  of  a  specific  hazard  in 
a  given  setting);  the  facility  design  criteria  that  are 
to  be  employed  in  a  facility  modification  review;  the 
definitions  of  the  risk  associated  with  a  given  hazard 
that  are  to  be  used  in  identifying  hazards,  etc. 

The  timing  of  the  required  actions.  An  example  of 
this  type  of  requirements  data  would  be  the 
specification  that  would  be  the  specification  that  the 
LOHHI  surveys  are  to  be  conducted  annually  for  each 
facility  and  installation. 
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2)  Examples  of  indicators  data  for  when  an  industrial  hygiene 
survey  or  an  abatement  action  is  to  be  conducted,  include: 
whenever  a  change  is  made  in  a  facility;  whenever  a  new  type 
of  supply  is  ordered  by  an  organizational  unit,  whenever  the 
number  of  reports  of  hazardous  substance  spills  in  a 
facility  exceed  'X*  in  a  given  time  period,  whenever  the 
number  of  employees  in  a  facility  exceeds  'X‘,  when  a  hazard 
is  identified  in  a  given  facility,  etc.  It  should  be  noted 
that  there  is  a  set  of  requirements  indicators  corresponding 
to  allowable  limits  for  medical  examinations  that  apply  to 
industrial  hygiene  surveys.  Just  as  a  given  abnormal 
reading  on  a  medical  examination  can  be  the  indicator 
determining  whether  and  which  follow-up  medical  surveillance 
is  needed,  so  there  can  be  allowable  limits  tables  for 
industrial  hygiene  survey  sampling  results  determining 
whether  and  which  preventive/ corrective  actions  are  to  be 
implemented. 

3)  The  most  important  applicability  factor  determining 
whether  and  which  type  of  industrial  hygiene  survey  or 
abatement  action  is  to  be  implemented  is  the  type  of 
hazard  expected  to  be  encountered.  In  most  instances,  it 

is  the  particular  type  of  hazard  (i.e.,  the  particular  value 
for  the  factor  hazard)  that  determines  the  frequency  and 
content  of  industrial  hygiene  surveys  and  abatement  actions. 
Other  factors  may  also  be  used  but  these  are  usually  factors 
that  are  equivalent  to  using  the  type  of  hazard  expected  as 
the  factor  determining  the  applicability  of  the  required 
action.  For  example,  industrial  hygiene  survey  schedules 
are  often  based  on  the  organizational  unit  occupying  a 
facility.  For  example,  facilities  occupied  by 
organizational  units  that  are  primarily  office  jobs  are 
usually  inspected  less  frequently  then  facilities  occupied 
by  motor  pool  activities.  In  this  case,  the  factor  deter¬ 
mining  the  timing  of  the  required  action  (i.e.,  the  timing 
of  the  industrial  hygiene  survey)  is  the  organizational 
unit  occupying  the  facility;  this  factor  is  used  because  of 
the  known  types  of  hazards  that  are  expected  to  be 
encountered  in  office  versus  motor  pool  types  of  organiza¬ 
tional  units. 

Many  additional  examples  similar  to  those  given  above  can  easily  be 
identified  by  examining  occupational  health  program  components.  These 
examples  show  the  underlying  similarity  between  the  use  modules  of  an 
occupational  health  information  system:  Almost  all  occupational 
health  program  components  include  data  on:  (1)  requirements,  (2) 
indicators  of  the  events  and  circumstances  in  which  a  requirement  is 
to  be  executed,  (3)  factors  determining  which  particular  requirement 
is  applicable.  Having  identified  this  underlying  similarity  in  the 
major  types  of  data  between  the  OHMIS  use  module,  the  next  step  in 
designing  OHMIS  is  to  identify  the  data  processing  functions 
required  to  process  these  3  types  of  data. 


5.3  DATA  PROCESSING  FUNCTIONS  OF  OHMIS:  Occupational  Health  Program 
Management  and  Quality  Assurance 

From  the  discussion  above,  it  is  clear  that  OHMIS  must  be  able  to 
input  and  store  data  on  requirements  (actions,  content  of  actions  and 
timing  of  actions),  requirement  indicators  and  requirement 
applicability  factors  (referred  to  here  collectively  as  requirements 
data).  However,  as  indicated  previously,  it  is  not  sufficient  for 
OHMIS  to  merely  be  a  repository  for  requirements  data.  The  objective 
of  OHMIS  is  to  provide  a  management  tool  that  will  be  used  in  the 
decision-making  processes  involved  in  the  operation  of  the  Department 
of  the  Army's  occupational  health  program.  P  iata  processing  goals 
of  OHMIS  should  be  to  reduce  the  occupational  alth  program 
management  time  and  resources  required  to  exe  '  the  requirements  of 
the  program  and  to  increase  the  efficiency  ant  uality  of  the 
program's  operation. 


While  most  of  the  occupational  health  program  jnents  of  the  Army 
do  have  documents  containing  data  on  requirements,  requirements 
indicators  and  requirements  applicability  factors,  the  systematic 
use  of  this  data  to  manage  the  Army's  occupational  health  program 
has  been  inhibited  by  the  lack  of  an  information  system  for 
processing  this  data.  Moreover,  the  review  of  existing  occupational 
health  information  systems  indicated  that  there  is  no  current  system 
specifically  designed  to  aid  in  the  decision-making  processes  involved 
in  the  identification  and  execution  of  the  requirements  of  an 
occupational  health  program.  The  conventional  concept  of  an 
occupational  health  information  system  appears  to  have  been  for  the 
system  to  act  merely  as  a  storage  bank  for  data  on  requirements  and  to 
facilitate  the  quick  retrieval  of  specified  requirements  data.  The 
potential  for  the  information  system  to  play  an  active  role  in  the 
execution  and  management  of  the  occupational  health  program 
requirements  does  not  appear  to  have  been  recognized.  Nevertheless, 
the  review  of  the  needs  and  potential  use  modules  of  OHMIS  indicates 
that  an  information  system  that  would  use  the  requirements  data  to 
support  the  day-to-day  operations  of  an  occupational  health  program  is 
greatly  needed.  Even  more  needed  is  an  information  system  that  will 
help  assure  that  the  DA  occupational  health  program  is  managed  in 
accordance  with  its  goals  and  policies.  In  fact,  the  justification 
for  an  occupational  health  information  system  that  performs  many  of 
the  critical  programmatic  functions  of  an  occupational  health  program, 
including  program  management,  is  believed  to  be  much  greater  than  the 
justification  for  the  conventional  systems  which  merely  store  the  data 
resulting  from  the  performance  of  ‘hese  functions.  For  these  reasons, 
the  concept  of  OHMIS  performing  many  of  the  occupational  health 
program  management  functions  was  employed  in  the  development  of  the 
core  data  processing  functions  for  OHMIS.  The  review  of  these 
functions  and  how  OHMIS  performs  them  constitutes  the  remaining 
portion  of  this  report. 

To  act  as  a  management  tool,  OHMIS  must  provide  support  for  the 
process  of  directing  the  DA' s  occupational  health  program  so  that  the 
operating  policies  and  goals  of  the  program---namely,  the 
identification  and  implementation  of  adequate  preventive/corrective 


arMons  for  occupational  hazards  —  are  met.  The  requirements  data  is 
used  to  define  the  specific  goals  and  policies  of  the  occupational 
health  program,  i.e.,  define  "adequate  preventive/ corrective  actions". 
In  general  terms,  the  function  of  OHMIS  information  in  the  management 
of  the  DA  occupational  health  program  is  to  continuously  supply 
management  with  the  current  information  about  the  status  of  the 
program  so  that  decisions  about  what  actions  are  needed  to  achieve  the 
policies  and  goals  of  the  program  can  be  made.  To  actively  assist  in 
the  management  of  the  occupational  health  program,  however,  the 
information  system  should  go  one  step  further.  OHMIS  should  provide 
the  information  needed  to  help  assure  that  the  goals  and  policies  of 
the  program  are  met.  To  perform  this  assurance  management  function, 
the  OHMIS  program  should  identify  the  situations  in  which  actions  are 
needed  and,  based  on  the  input  from  occupational  health  program 
managers  and  personnel  on  the  prescribed  policies  and  goals 
"remember"  what  types  of  actions  are  needed  to  operate  the  program 
as  planned,  i.e.,  in  accordance  with  the  program  policies  and  goals. 

By  performing  this  assurance  management  information  system  function, 
OHMIS  will  provide  decision  makers  with  information  comparing  the 
current  status  of  the  occupational  health  program  component  to  the 
policies  and  goals  for  that  component,  thereby  cueing  managers  about 
when  corrections  are  needed  to  reduce  the  differences  between  the 
current  status  and  the  goals  for  the  program.  Thus,  the  fundamental 
assurance  management  functions  of  OHMIS  should  be  to  identify  the 
occasions  in  which  previously  specified  required  actions  are  needed 
in  order  to  achieve  the  goals  of  the  program  and  to  provide  managers 
at  all  levels  with  information  on  the  status  of  the  implementation  of 
these  actions. 

Specifically,  OHMIS  will  assure  that  specified  requirements  are: 

1)  Triggered,  i.e.,  the  occasions  in  which  the  requirements 
apply  are  routinely  identified  by  all  levels  of  DA 
occupational  health  program  managers;  and, 

2)  Audited,  i.e.,  the  implementation  of  the  requirements  is 
monitored  and  evaluated  to  assure  that  the  requirements  are 
completed  in  accordance  with  the  specified  performance 
criteria  for  the  requirements,  i.e.,  in  accordance  with  the 
content  and  timing  requirements  associated  with  the  required 
actions. 

These  two  management  functions  are  currently  being  performed  to  a 
large  degree  by  OA  occupational  health  managers  and  personnel. 

However,  OHMIS  will  help  assure  that  these  functions  are  done  much 
more  systematically  and  consistently  than  can  be  achieved  without  an 
assurance  management  information  system.  The  OHMIS  information  system 
will  have  the  capability  to  "remember"  and  monitor  requirements  with  a 
much  higher  degree  of  accuracy  and  comprehensiveness  than  is  possible 
by  manual  program  management. 

5.4  RECOMMENOED  SYSTEM  DESIGN  FOR  OHMIS 

FIGURES  5-1  and  5-2  show  the  recommended  system  design  for  OHMIS  in 
terms  of  the  data  processing  functions  that  it  will  perform.  These 
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FIGURES  show  how  OHMIS  will  function  to  assure  that  the  DA 
occupational  health  program  operates  in  accordance  with  the  policies 
and  procedures  specified  by  the  program  managers  at  all  levels. 

FIGURE  5-1  shows  the  four  basic  data  types  that  must  be  initially 
"loaded"  into  the  OHMIS  data  base  prior  to  the  start  of  the  operation 
of  the  OHMIS  for  the  assurance  management  data  processing  functions  to 
be  performed.  The  first  three  of  these  data  types  are  the  major, 
common  data  elements  found  in  the  current  DA  occupational  health 
program  descriptions,  as  identified  above,  namely,  requirements  data, 
requirements  indicators,  and  requirements  applicability  factors  data. 
Each  of  these  three  types  of  data  has  been  given  a  code  in  order  to 
show  on  FIGURE  5-2  how  each  of  these  types  of  data  is  used  to  operate 
OHMIS.  Specifically,  the  4  major  types  of  data  that  must  be  initially 
loaded  into  OHMIS  are: 

A)  Requirements  data.  This  includes  data  on  required  actions 
or  tasks  (Data  Type  Al),  data  on  the  content  of  a  required 
action  (usually  specified  on  the  OHMIS  data  entry  forms  that 
are  used  to  perform  actions  and  identified  as  Data  Type  A2) 
and  data  on  the  timing  of  requirements  (Data  Type  A3). 

B)  Requirements  indicators.  This  is  data  on  the  events  or 
information  that  should  trigger  a  requirement.  This  is 
the  data  that  OHMIS  will  use  to  perform  the  first  major 
assurance  function,  namely,  that  of  identifying  the 
circumstances  in  which  a  requirement  applies.  As  indicated 
above,  requirements  indicators  data  can  be  dates 
(identified  as  Data  Type  Bl),  data  that  signals  the 
occurrence  of  events  that  are  to  trigger  requirements 
(identified  as  Data  Type  B2)  or  values  for  abnormal  readings 
(allowable  limits)  that  should  trigger  requirements 
(identified  as  Data  Type  B3). 

C)  Requirements  applicability  factors  data.  This  is  the  data 
on  the  factors  that  determine  whether  a  requirement  applies 
and,  if  so,  which  particular  requirement  applies.  This  type 
of  data  has  been  identified  as  Data  Type  C. 

D)  In  addition  to  the  above  3  types  of  data,  a  further  data 
type  (Data  Type  D)  must  be  loaded  onto  the  OHMIS  data  base 
prior  to  the  operation  of  OHMIS.  This  is  data  on  the 
avai labi 1 ity  of  DA  occupational  health  program  personnel 
to  perform  actions  specified  by  the  requirements  data. 

This  data  includes  the  identification  of  which  persons  are 
qualified  to  perform  each  required  action  and  the  man-hours 
available  to  perform  required  actions  at  any  given  point  in 
time.  This  information  is  used  by  OHMIS  to  automatically 
schedule  a  task  as  soon  as  the  OHMIS  program  has 
identified  this  task  as  a  required  action. 

FIGURE  5-2  shows  the  data  processing  by  which  OHMIS  uses  the  data 
types  to  perform  the  occupational  health  program  management  assurance 
function.  The  data  processing  decisions  and  steps  in  which  each  of 
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the  4  data  types  are  used  are  shown  on  FIGURE  5-2  through  the  symbol 
of  a  small  circle  with  the  letter  identifying  a  data  type  contained  in 
the  circle. 

FIGURE  5-2  shows  the  functions  that  OHMIS  will  perform  to  assure  that 
all  DA  occupational  health  program  requirements  are  triggered  and 
audited  and  the  points  at  which  the  data  that  was  preloaded  into  OHMIS 
(i.e.,  data  types  A  through  D)  are  used  to  perform  these  functions. 
Specifically,  FIGURE  5-2  shows  that  OHMIS  uses  the  preloaded  data  to: 

1)  Decide  whether  a  requirement  should  be  triggered.  This 
includes  determining  whether  a  timing  requirement  has  been 
specified  and,  if  so,  generating  a  new  set  of  date 
requirements  indicators  data  (data  type  Bl). 

2)  Decide  what  requirements  should  be  triggered,  i.e.,  what 
requirements  are  applicable. 

3)  Schedule  the  task  specified  by  the  requirements. 

4)  Generate  the  OHMIS  forms  needed  to  conduct  the  required 
tasks  in  accordance  with  the  content  specifications  of  the 
requirements. 

5)  Monitor  outstanding  tasks  and  forms  until  they  are 
completed. 

6)  Provide  a  means  for  entering  data  from  OHMIS  forms.  This 
entry  of  data  will  result  in  the  OHMIS  program  starting  the 
core  data  processing  functions  over  again,  beginning  with 
step  (1),  i.e.,  the  program  will  determine  whether  the  data 
entered  on  an  OHMIS  form  should  trigger  a  requirement;  if 
so,  what  requirement  should  be  triggered;  etc. 

The  exact  data  processing  algorithms  to  which  each  of  these  steps  is 
accomplished  is  given  in  Section  VI,  which  provides  the  Functional 
Data  Flows  for  a  recommended  system  design  for  OHMIS. 
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Functional  Data  Flows 


i 


1 


VI.  RECOMMENDED  SYSTEM  DESIGN  -  PART  2 
Functional  Data  Flows 


This  Section  of  the  report  provides  the  detailed  IPO's  (Input/ 
Processing/Output)  of  the  recommended  OHMIS  system  design  in  sufficient 
detail  for  programming.  The  data  processing  algorithms  for  the  core 
OHMIS  data  processing  functions  are  given  in  I/P/Os  called  Functional 
Data  Flows.  Section  6.1  provides  clarification  of  the  scope  and 
limitations  of  this  Section  of  the  report.  Section  6.2  provides 
definitions  for  the  set  of  special  terms  used  in  the  Functional  Data 
Flows.  Section  6.3  describes  the  four  basic  types  of  data  used  in  the 
core  OHMIS  data  processing  functions.  Section  6.4  provides  an  overview 
of  each  of  the  core  data  processing  functions  in  the  OHMIS  system. 
Section  6.5  provides  the  Menu  Selection  Sequences  for  the  OHMIS  core 
programs.  Section  6.6  provides  a  detailed  description  of  the  28  data 
sets  (inputs)  used  in  the  OHMIS  core  programs.  Section  6.7  provides 
the  17  outputs  generated  by  the  OHMIS  core  programs.  Section  6.8 
provides  the  IPO  Functional  Data  Flows  for  each  of  the  eleven  core  data 
processing  functions  in  OHMIS. 

6.1  SCOPE  OF  THE  FUNCTIONAL  DATA  FLOWS 

The  purpose  of  the  Functional  Data  Flows  given  in  this  Section  of  the 
report  is  to  provide  a  description  of  the  generic  (core)  data 
processing  functions  of  the  recommended  OHMIS  system  at  a  level  of 
detail  that,  with  the  exception  of  the  decisions  about  file  structure 
and  data  element  field  sizes,  is  sufficient  to  be  suitable  for 
programing,  provided  guidance  is  given  to  the  programmer  at  various 
intervals.  Specifically,  the  Functional  Data  Flows  provide  the  IPOs  for 
performing  the  requirements  triggering  and  monitoring  functions  shown  on 
FIGURE  5-2.  The  operative  phrase  in  the  above  statement  is  1  data 
processing  functions'.  Specifically,  this  document  is  not  a  user's 
manual .  That  is,  this  Section  of  the  report  does  not  describe  the 
procedural  functions  needed  to  operate  the  OHMIS  program.  It  is 
confined  to  the  data  processing  functions,  many  of  which  will  be 
transparent  to  the  user.  It  covers  in  great  detail  the  generic  process 
of  inputting  OHMIS  data  and  assuring  that  the  DA  requirements  for  an 
Occupational  Health  Program  that  are  affected  by  this  data  are 
identified  and  monitored  until  completed.  However,  the  description  of 
the  day-to-day  procedures  that  the  Industrial  Hygienist  and  Occupational 
Health  Nursing  staff  at  the  DA  installation  level  (i.e.,  the  day-to-day 
users  of  OHMIS)  will  employ  to  collect  and  use  data  from  the  OHMIS 
system  in  the  operation  of  an  Occupational  Health  Program  will  need  to 
be  described  in  another  document,  referred  to  here  as  the  "OHMIS  Users' 
Procedures  Manual"),  that  is  not  within  the  scope  of  work  under  which 
this  document  was  prepared. 

The  OHMIS  program  has  been  deliberately  designed  to  allow  for  frequent 
and  extensive  changes  and  for  local  variations  in  the  specific  types  of 
data  collected,  the  requirements  prescribed  and  monitored  and  the 
analyses  made.  To  do  this,  it  was  necessary  to  define  the  OHMIS  system 
in  generic  terms.  That  is,  the  core  program  logic  for  the  OHMIS 
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system  given  in  this  report  covers  the  input/processing/output 
functions  for  OHMIS  data.  The  design  of  the  OHMIS  system  is  such 
that  all  of  the  technical  and  programmatic  data  (referred  to  as 
requirements  data)  is  input  to  the  OHMIS  data  base  at  the  onset  of  the 
system  in  accordance  with  current  DA  policies  and  local  installation 
needs  and  modified  as  needed  to  comply  with  changes  in  regulations  and 
needs. 

Thus,  for  example,  the  core  OHMIS  program  logic  provides  the  mechanism 
for  the  user  to  define  the  exact  types  and  content  of  each  OHMIS  medical 
examination  form.  This  not  only  means  that  different  forms  can  be 
developed  by  different  medical  specialities,  but  different  forms  can  be 
developed  for  different  job  classes,  depending  on  the  types  of  hazards 
for  which  medical  surveillance  is  expected  to  be  needed  for  each  job 
class.  Of  course,  any  modifications  in  the  forms  needed  to  comply  with 
newly  identified  hazards,  changes  in  regulations,  special  studies,  etc. 
can  readily  be  made.  Also,  using  the  OHMIS  design,  it  will  be  possible 
to  make  any  special  adaptations  to  these  forms  that  are  needed  in  an 
instal Jation.  The  core  OHMIS  program  also  provides  a  mechanism  for 
inputting  the  data  on  each  form  that  is  developed  for  evaluating  the 
data  entered  on  these  forms  and  for  triggering,  scheduling  and 
monitoring  the  implementation  of  requirements  prescribed  by  the  user  for 
responding  to  the  specific  results  of  the  evaluations  of  the  data 
entered  on  these  forms. 

The  description  of  the  OHMIS  program  logic  provided  in  this  report  gives 
detailed  data  processing  steps  for  each  of  these  mechanisms  and  is  there¬ 
fore  comprehensive.  However,  no  reference  to  any  particular  input  form 
is  made  except  in  examples  to  show  how  the  data  processing  functions 
would  be  used.  The  input  programs  that  are  described  in  this  report 
cover  processes  such  as  the  input  of  requirements  data  or  scheduling 
resources  data.  The  input  of  the  data  from  a  completed  form  is  also 
described.  However,  these  detailed  data  processing  steps  refer  to  the 
input  of  data  from  any  OHMIS-designed  form  (because  the  data  processing 
has  been  structured  to  be  the  same  for  any  form  regardless  of  its 
content)  and,  therefore,  these  steps  do  not  describe  the  contents  of  any 
particular  form. 

Similarly,  because  the  OHMIS  program  envisions  a  user  query  type  of 
mechanism  for  generating  outputs,  the  OHMIS  outputs  described  in  this 
report  are  also  generic  in  nature.  The  user  query  system  for  generating 
outputs  allows  the  user  to  generate  an  output  covering  any  data  set 
defined  by  the  user  or  any  set  of  contents  from  an  OHMIS-designed  form 
defined  by  the  user.  Therefore,  it  is  not  necessary  to  describe  the 
contents  of  any  particular  output  in  this  report.  The  outputs  that 
are  described  in  this  report  cover  the  types  of  outputs  needed  to 
manage  and  audit  an  Occupational  Health  Program,  rather  than  any 
particular  set  of  Occupational  Health  Program  data.  For  example,  the 
contents  of  an  output  listing  all  required  actions  needed  for  the 
Occupational  Health  Program  that  have  been  completed  is  given  in  this 
report.  This  output,  called  the  Outstanding  Requirements  List  (Output 
04)  is  a  generic  output  that  can  be  used  for  a  wide  variety  of 
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purposes,  ranging  from  summarizing  identified  corrective  actions  that 
need  to  be  implemented  (i.e.,  an  abatement  log)  to  listing 
investigations  that  need  to  be  made  for  organizational  units  having 
excessive  numbers  of  incidents  involving  hazardous  substances  (i.e.,  a 
potential  hazard  identification  log).  The  exact  use  made  of  this  output 
will  depend  on  the  type  of  outstanding  requirements  that  the  user 
requests  for  any  particular  generation  of  the  output. 

Similarly,  the  Daily  Schedule  (Output  014)  described  in  this  report,  can 
be  used  to  describe  the  scheduling  of  a  wide  variety  of  tasks,  ranging 
from  routine  medical  examinations  to  Industrial  Hygiene  surveys.  The 
exact  contents  of  outputs  are  not  described;  only  the  format  and 
functions  of  outputs  are  described.  Many  of  the  outputs  described  in 
this  report  are  used  solely  for  information  system  management  functions. 
For  example,  the  Outstanding  Data  Requests  Lists  (Output  013)  which 
tells  the  OHMIS  Data  Processing  Staff  what  forms  have  been  generated  and 
sent  out  for  completion  but  have  not  been  returned,  is  used  to  ensure 
and  facilitate  quality  control  of  OHMIS  data. 

The  'Menus'  shown  in  Section  6.5  provide  the  points  of  user  input  and 
user  requests  for  output  for  the  core  OHMIS  functions.  Not  all 
functions  are  listed  on  the  Menus,  because  many  of  the  functions  are 
transparent  to  the  user.  Sections  6.6  and  6.7  provide  a  series  of  Data 
Sets  (inputs)  and  a  series  of  Outputs  for  each  OHMIS  function.  Those 
data  processing  steps  that  are  merely  entry  of  or  output  of  data  element 
types  that  have  been  described  in  detail  in  the  Data  Sets  and/or  Outputs 
are  not  redescribed  in  the  Functional  Data  Flows. 

Only  a  tentative  file  structure  for  the  OHMIS  data  base  has  been  defined 
in  this  report.  This  is  because  it  is  felt  that  the  decision  on  the 
file  structure  should  await  the  final  program  logic  and  documentation 
and  the  exact  hardware  conf iguration  chosen  for  operating  OHMIS.  The 
tentative  file  structure  provided  for  in  this  report  is  based  on 
separate  records  for  each  OHMIS  form  specification.  However,  this  file 
structure  is  only  offered  in  order  to  provide  a  means  of  describing  the 
data  processing  functions.  That  is,  it  provides  a  storage  framework 
with  which  to  describe  the  manipulation  of  the  OHMIS  data.  It  is 
expected  that  significant  changes  in  this  file  structure  will  be  made 
when  the  final  storage  design  is  determined. 

Although  the  Functional  Data  Flows  given  in  this  report  do  provide  a 
complete  set  of  detailed  data  processing  steps  for  performing  each 
function,  it  is  expected  that  some  aspects  of  the  particular  method 
described  here  for  data  processing  will  be  changed  in  the  final  program 
logic  to  add  greater  efficiency  or  to  better  fit  the  final  file 
structure  chosen  for  OHMIS.  These  Functional  Data  Flow  steps  should  be 
considered  as  an  example  of  how  the  data  processing  might  be 
conducted;  each  example  given  provides  a  complete  data  processing  logic 
that  meets  all  of  the  all  of  the  functional  requirements  that  OHMIS 
should  be  designed  to  perform. 

Before  proceeding  to  the  general  description  of  the  OHMIS  program,  a 
series  of  definitions  of  terms  used  in  this  Section  of  the  report  and  in 
the  Functional  Data  Flows  is  given. 
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6.2  DEFINITION  OF  TERMS 

In  order  to  describe  the  OHMIS  system  in  a  generic  way  without 
prescribing  a  particular  file  structure  and  without  defining  any 
particular  forms  or  outputs  (other  than  management  outputs),  it  was 
necessary  to  generate  a  lexicon  of  terms.  As  these  terms  are  used 
throughout  Section  VI  of  this  report,  this  Section  begins  by  defininq 
these  terms. 

6.2.1  'Code  Types'  vs.  'Identifiers' 

A  basic  distinction  that  is  made  throughout  this  discussion  is  the 
difference  between  a  name  or  number  that  classifies  a  person  or  thing 
(referred  to  as  Code  Types)  and  a  name  or  number  that  identifies  a 
particular  item  or  person  (referred  to  as  Identifiers) .  There  are 
many  examples  of  this  distinction,  but  a  few  common  ones  are: 

o  A  facility  type  code  might  be  a  code  for  all  facilities 
classified  as  'food  service  areas',  while  a  facility 
identifier  would  identify  a  particular  building,  e.g., 
‘building  HT-4'  (number)  or  the  'building  on  H  and  I  Streets' 
(name) ; 

o  A  job  class  type  might  be  'welders',  while  the  identifier  for 
a  job  class  would  identify  a  particular  position  in  a 
particular  organizational  unit  and  in  a  particular 
installation; 

o  A  task  type  might  be  'Industrial  Hygiene  surveys',  while  an 
example  of  a  particular  task  that  would  be  assigned  an 
identifier  would  be  ‘Industrial  Hygiene  survey  in  facility 
HT-4,  conducted  on  1/3/83' ;  etc. 

The  primary  difference  shown  by  these  examples  is  that  a  type  code  has  a 
meaning  and,  therefore,  says  something  about  the  person,  idea  or  thing 
being  described,  while  an  identifier  has  no  meaning  attached  to  it  and 
is  used  only  to  assign  a  unique  value  to  a  particular  person,  activity 
or  thing  in  order  to  precisely  distinguish  it  from  all  other  persons  or 
things. 

In  the  terminology  used  in  this  report,  the  number  used  to  classify 
a  person,  thing  or  idea  (e.g.,  a  task)  is  called  a  code.  The  OHMIS 
system  will  include  a  vocabulary  word/phrase  list  that  provides  a 
dictionary  with  the  meanings  of  each  code.  There  will  be  several  sets 
of  such  codes.  Thus,  there  will  be  a  set  of  codes  and  meanings  for 
types  (classif ications)  of  facilities,  job  classes,  forms,  documents, 
tasks,  requirements,  etc.  The  exact  nature  and  structure  of  these  OHMIS 
vocabulary  words/phrases  will  be  developed  at  a  later  date.  However, 
throughout  the  discussion  in  this  report,  it  has  been  necessary  to  refer 
to  and  distinguish  different  sets  of  codes.  To  identify  each  set  of 
codes  that,  at  this  time,  is  known  to  be  needed  for  the  operation  of 
OHMIS,  the  term  Code  Type  was  originated.  Thus,  to  make  it  clear  in  a 
Functional  Data  Flow  that  what  is  referred  to  is  the  set  of  codes  that 
will  be  developed  to  classify  faci 1 i ty  types  as  opposed  to  document 
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types,  the  Functional  Data  Flows  refer  to  the  set  of  codes  for  facility 
types  as  Code  Type  7  (CT7  in  abbreviated  form)  and  the  set  of  codes 
that  will  be  developed  for  document  types  as  Code  Type  3  (CT3).  FIGURE 
6-1  shows  the  list  of  Code  Type  numbers  used  in  this  report.  This  list 
is  by  no  means  an  exhaustive  list  of  Code  Types  that  will  be  needed  in 
OHMIS.  This  list  is  only  those  particular  sets  of  codes  that  were 
needed  to  describe  the  eleven  core  data  processing  functions  of  OHMIS  or 
to  give  examples  of  how  these  functions  will  work.  The  actual  codes 
developed  for  the  operation  of  OHMIS  will  be  a  combination  of  existing 
standard  codes,  e.g.,  those  used  by  DoD  and  other  organizations,  and  the 
new  codes  required  to  meet  the  special  needs  of  OHMIS. 

The  terminology  used  in  this  report  for  the  number  used  to  identify  a 
particular  item  or  person  or  idea  is  an  Identifier.  As  with  code  types, 
there  will  be  a  number  of  sets  of  identifiers  in  the  OHMIS  system, 
each  set  providing  a  number  to  uniquely  identify  a  person  or  thing  in 
that  set.  For  example,  there  will  sets  of  identifiers  identifying 
persons  {called  employee  identifiers;  these  will  probably  be  Social 
Security  Numbers),  facilities,  documents,  etc.  FIGURE  6-2  shows  the 
list  of  sets  of  identifiers  used  in  this  report.  Each  set  of 
identifiers  has  been  given  a  number  in  order  to  make  clear  which  set 
of  identifiers  is  being  referred  to.  For  example.  Identifier  3  (ID3 
in  abbreviated  form)  was  used  to  refer  to  the  set  of  identifiers  that 
will  be  developed  to  itemize  documents  in  the  OHMIS  system. 

As  with  the  Code  Type  list  in  FIGURE  6-1,  the  list  of  sets  of 
Identifiers  in  FIGURE  6-2  is  not  exhaustive,  but  only  presents  those 
sets  of  identifiers  needed  to  describe  the  core  OHMIS  functions.  Many 
of  the  identifiers  shown  on  FIGURE  6-2  are  identifiers  used  to 
distinguish  a  Data  Set  { DS ) .  Thus,  each  separate  set  of  Requirements 
Check  Request  Data  (Data  Set  2)  in  the  OHMIS  system  will  be  assigned  an 
identifier  to  uniquely  identify  that  set  of  data  from  all  other  sets  of 
Data  Set  2s.  In  the  convention  used  in  this  report,  the  set  of 
identifiers  that  is  used  to  distinguish  different  Data  Set  2s  is 
referred  to  as  an  Requirement  Check  Request  Identifier  and  is  assigned 
the  number  101  to  distinguish  it  from  other  sets  of  identifiers  used  in 
this  report. 

A  comparison  between  FIGURES  6-1  and  6-2  will  show  that  there  is  often  a 
set  of  Code  Types  and  a  set  of  Identifiers  for  the  same  item.  This  is 
because  items  can  be  assigned  both  an  Identifier  and  a  Code  Type.  Thus, 
a  facility  can  be  classified  as  a  'food  service  area1  and  assigned  the 
Code  Type  associated  with  that  meaning  for  facility  types  and  be 
identified  as  'Building  HT-4'  and  assigned  an  Identifier  to  distinguish 
this  particular  building.  As  with  Code  Types,  the  OHMIS  data  base  will 
keep  a  list  of  the  names  associated  with  each  Identifier.  To  the 
greatest  extent  possible,  existing  Identifiers  will  be  used,  e.g., 
existing  building  numbers  will  be  used  to  identify  facilities.  However, 
as  the  historical  data  maintained  in  OHMIS  is  extensive  and  critical  to 
its  use,  stringent  quality  control  measures  will  need  to  be  exacted  to 
ensure  that  a  code  or  an  identifier  is  used  only  once,  that  its  meaning 
does  not  change,  etc. 
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TITLES  OF  CODE  TYPES 


Code  Type  Number 
CT1 
CT2 
CT3 

CT4 

CT5 

CT6 

CT7 

CT8 

CT9 

CT10 

CT11 


Code  Type  Title 

OHM  IS  user  type  (see  ID13) 

OHM IS  position  type  (see  ID14) 

OHMIS  requirement  type  (see  ID5,  ID6,  and 
ID9) 

Data  element  type  (see  DS7) 

Organizational  level  type  (see  ID7,  ID8, 

I DIO ,  1011 ,  and  ID12) 

Document  type  (see  ID3) 

Facility  type 

Task  type  (see  DS23) 

Form  type 

Identifier  type  (see  Identifier  Numbers) 
Time  use  code 
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FIGURE  6-2 


TITLES  OF  IDENTIFICATION  NUMBERS 


Identification 

Number 

IDl 

ID2 

ID3 

ID4 

105 

ID6 

ID7 

ID8 

ID9 

I  DIO 
IDll 
I D 12 
ID13 

1 014 

1015 
ID16 
IDl  7 
I D 18 
1019 
ID20 


Identification 

Title 

Requirements  check  request  identifier  (see 
DS2) 

Triggering  step  identifier 
Documentation  identifier  (see  CT6) 

Employee  identifier 

Requirement  application  identifier  (see  DS3, 
DS4,  and  DS17) 

OHMIS  requirement  (recommendation)  identifier 
(see  CT3;  DS1) 

Job  class  identifier 

Facility  identifier 

Requirement  implementation  identifier  (see 
DS5) 

OHMIS  service  area  identifier 

Installation  identifier 

Organizational  unit  identifier 

OHMIS  user  identifier  (see  CT1) 

OHMIS  position  identifier  (see  CT2) 

Document  subpart  identifier  (see  ID3) 

Form  specification  identifier  (see  DS10) 

Form  subpart  identifier  (see  DS11) 

Completed  form  identifier  (see  DS 14 ) 

Forms  application  identifier  (see  DS13) 

Allowable  limits  application  identifier  (see 
DSI6 ) 


FIGURE  6-2  (Cont'd.) 


Identification 

Number 


Identification 

Title 


1021 


Missing  data  element  type  information  identi¬ 
fier  (see  DS19) 


1022 

ID23 

1024 

ID25 

1026 

ID27 

ID28 


Allowables  limit  check  request  identifier 
(see  DS18) 

Task  identifier  (see  DS24) 

Time  period  specification  identifier  (see 
DS20) 

Allowable  limits  table  identifier  (see  0L 19) 
Contact  identifier  (see  DS28) 

Monthly  schedule  identifier  (see  DS27) 

Weekly  schedule  identifier  (see  DS26) 
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6.2.2  Terms  for  Types  of  Persons/Groups 

Eight  terms  have  been  used  to  identify  several  types  of  persons  or 
groups  of  persons  that  bear  a  special  relationship  to  OHMIS.  These 
eight  terms  are:  1)  OHMIS  service  area;  2)  employee;  3)  OHMIS  user;  4) 
OHMIS  Data  Processing  Staff;  5)  OHMIS  position;  6)  organizational  unit; 
7)  requirement  implementation  unit;  and  8)  forms  unit. 

1)  OHMIS  Service  Area.  This  term  is  used  to  identify  a  boundary 
within  which  all  OHMIS  functions  will  be  performed  by  the  same  OHMIS 
office.  In  most  cases,  the  boundaries  for  an  OHMIS  service  area  will  be 
the  same  as  the  boundaries  for  an  installation,  but  in  some  cases  more 
than  one  small  installation  may  be  served  by  one  OHMIS  office.  This  is 
the  reason  that  the  term  'OHMIS  service  area1  is  used  instead  of 
installation.  During  initial  implementation  of  OHMIS,  the  boundaries  of 
each  OHMIS  service  area  will  be  defined.  Within  such  a  boundary,  all  of 
the  data  on  the  persons,  facilities  and  supplies  (hazards),  etc.  will  be 
handled  by  the  same  OHMIS  service  area  office.  Each  OHMIS  service  area 
will  be  assigned  an  OHMIS  service  area  identifier  (shown  on  FIGURE  6-2 
as  the  ID10  set  of  identifiers). 

Almost  all  OHMIS  data  processing  functions  will  be  handled  by  OHMIS 
service  areas.  Each  service  area  may  develop  its  own  specifications 
for  forms,  its  own  sets  of  Occupational  Health  Program  requirements,  its 
own  scheduling  system,  etc.  Most  sets  of  data  in  the  OHMIS  data  base 
will  have  an  OHMIS  service  area  identifier  (ID10)  on  them. 

Each  OHMIS  service  area  will  interact  with  one  and  only  one  of  the  five 
Regional  Data  Centers  in  VIABLE.  It  is  envisioned  that  the  OHMIS  data 
base  storage  and  retrieval  system  from  the  VIABLE  Regional  Data  Centers 
will  be  organized  to  enable  ready  access  by  an  OHMIS  user  from  a  given 
service  area  to  all  current  data  on  the  persons,  facilities,  outstanding 
requirements,  etc.  for  that  OHMIS  service  area. 

Most  "things"  (as  distinguished  from  "persons")  will  always  remain  in 
the  same  OhMIS  service  area,  e.g.,  a  facility  will  always  be  in  one  and 
only  one  service  area.  However,  people  will  necessarily  move  from  one 
OHMIS  service  area  to  another.  It  will  be  necessary  to  organize  the 
interaction  between  each  OHMIS  service  area  and  the  VIABLE  Regional  Data 
Centers  so  that  tne  current  data  on  a  person  who  has  newly  moved  into  an 
OHMiS  service  area  can  be  retrieved  and  used  routinely  by  that  service 
area  without  having  to  use  excessive  data  communication  resources. 

2)  Employee.  This  term  iu  used  generically  to  refer  both  to 
civilians  employed  by  the  Department  of  the  Army  and  to  military  members 
of  the  Department  of  the  Army. 

3)  OHMIS  User.  This  term  is  used  to  refer  to  the  group  of  persons 
who  will  be  directly  interacting  with  the  OHMIS  computer  system.  These 
persons  will  be  authorized  to  input  and  output  data  from  OHMIS.  Each 
user  will  be  assigned  an  OHMIS  user  identifier  (shown  on  FIGURE  6-2  as 
the  set  of  identifiers  with  the  number  ID13)  and  a  'password'.  The 
combination  of  the  user's  I Dl 3  number  and  password  will  be  used  to 
control  the  types  of  interactions  with  the  OHMIS  data  base,  e.g.,  what 
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types  outputs  may  be  generated,  what  changes  may  be  made  to  the  data, 
etc.  An  employee  who  is  also  an  OHMIS  user  will  thus  have  both  an 
employee  identifier  (Identifier  Set  104)  and  an  OHMIS  user  identifier 
(1013). 

4)  OHMIS  Data  Processing  Staff.  It  is  envisioned  that  OHMIS  users 
will  be  classified  into  several  groups  by  the  type  of  relationship 

they  bear  to  OHMIS.  (This  set  of  Code  Types  is  identified  on  FIGURE  6-1 
as  CT1.)  One  particular  type  of  OHMIS  user  that  is  referred  to 
throughout  this  report  is  the  OHMIS  Data  Processing  staff  person.  An 
OHMIS  Data  Processing  staff  person  is  expected  to  be  identified  for  each 
OHMIS  service  area.  This  person  need  not  be  a  computer  programmer  or 
even  ,'iave  extensive  knowledge  of  computer  systems.  In  most  cases  it  is 
envisioned  that  this  person  will  be  a  clerk  or  a  person  who  performs 
clerical  duties.  It  is  recognized  that  it  is  not  possible  to  have  a 
person  with  computer  science  background  in  every  OHMIS  service  area. 

This  term  is  only  used  to  identify  the  person  who  will  have  primary 
responsibility  for  handing  routine  OHMIS  data  processing  functions,  such 
as  the  generation  of  the  Daily  Schedules  (Output  014)  in  a  given  OHMIS 
service  area. 

5)  OHMIS  Position.  This  is  a  term  used  to  identify  a  person  in  an 
office  or  job  class  that  performs  a  particular  OHMIS  function.  As  with 
OHMIS  users,  there  are  OHMIS  position  identifiers  (1014s)  and  OHMIS 
position  type  codes  (CT2s).  Examples  of  types  of  OHMIS  positions 
would  be  an  Occupational  Health  Nurse,  Industrial  Hygienist,  Physician, 
etc.  Some  positions  outside  of  the  OHMIS  organization  will  also  be 
classified  as  to  their  relationship  to  OHMIS  and  will  therefore  need  to 
have  an  OHMIS  position  identifier.  For  example,  it  is  anticipated  that 
certain  positions  in  the  personnel  office  will  need  to  be  designated  as 
OHMIS  positions  in  order  to  classify  and  refer  to  data  about  these 
positions  in  the  OHMIS  data  base.  Also,  it  is  envisioned  that  a  point 
of  contact  with  various  organizational  units  will  be  needed.  The  person 
in  a  job  class  or  organizational  unit  designated  as  the  point  of  contact 
for  OHMIS  may  need  to  be  classified  and  assigned  an  OHMIS  position 
identifier.  Throughout  this  report,  such  persons  are  referred  to  as  the 
type  of  person  filling  the  OHMIS  Liaison  Supervisor  type  of  position. 

6)  Organizational  Unit.  This  term  is  used  generically  to  refer  to 
any  set  of  individuals  grouped  organizationally  at  a  level  higher  than 
job  classes.  This  term  applies  to  both  military  groups  and  civilian 
groups. 

7)  Requirement  Implementation  Unit.  This  term  is  the  general  term 
used  to  identify  the  particular  person  or  thing  about  which  a  particular 
requirement  will  be  implemented.  For  example,  a  requirement  for  a 
medical  exam  will  have  the  employee  identifier  of  the  person  of  will 
receive  the  exam  as  the  requirement  implementation  unit.  For  a  require¬ 
ment  to  conduct  an  IH  survey,  the  facility  identifier  of  the  facility  in 
which  the  survey  will  be  conducted  is  the  requirement  implementation 
unit. 

8)  Forms  Unit.  The  person  or  thing  which  is  described  by  a 
particular  set  of  data  on  a  form  is  referred  to  the  forms  unit.  For 
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example,  on  a  form  providing  data  describing  a  hazard,  the  identifier 
for  the  hazard  would  be  the  forms  unit. 

6.2.3  Formatting  Terms 


Five  terms  have  been  used  to  identify  a  particular  component  of  the  data 
processing  description  given  in  this  report.  These  terms  are:  1)  Menu 
Selection  Sequence;  2)  Data  Set;  3)  Data  List;  4)  Output;  and  5) 
Functional  Data  Flows,  also  called  Functions. 

1)  Menu  Section  Sequence.  The  OHMIS  programs  are  "Menu  driven," 
that  is,  a  user  indicates  which  program  component  is  desired  by 
selecting  and  entering  the  value  for  one  of  the  items  on  a  Menu 
presented  to  the  user.  Section  6.5  of  this  report  gives  the  Menus  for 
the  OHMIS  core  data  processing  functions.  Often  it  will  be  necessary 
for  the  user  to  make  a  selection  from  a  series  of  Menus,  each  selection 
leading  to  another  Menu  from  which  the  user  further  defines  his/her 
request.  A  particular  series  of  selections  from  the  Menus  provided  in 
OHMIS  is  referred  to  in  this  report  as  a  'Menu  Selection  Sequence'. 

Thus,  in  Section  6.5,  it  can  be  seen  that  'Menu  Selection  Sequence 
1.2.3*  would  refer  to  the  selection  made  by  selecting: 

o  Item  *  1 '  on  Menu  0  (first  level  menu,  which  would  result  in 
the  user  being  presented  with  Menu  1; 

o  Item  '2'  on  Menu  1  which  would  result  in  the  user  being 
presented  with  Menu  1.2;  and 

o  Item  '3'  on  Menu  1.2. 

As  can  be  seen  in  the  Menus  given  in  Section  6.5,  the  user  would  select 
‘Menu  Selection  Sequence  1.2.3'  if  s/he  wishes  to  'Generate  an 
Outstanding  Requirements  Checks  Needed  List  (Output  02)'. 

2)  Data  Set.  This  terms  refers  to  a  group  of  inputs  of  data  or  a 
configurations  of  data  element  types  used  in  the  functional  data  flows 
for  the  OHMIS  core  functions.  FIGURE  6-3  provides  a  list  of  the  titles 
of  these  data  sets.  As  can  be  seen,  a  Data  Set  is  identified  by  a  ' DS * 
number,  e.g.,  DS1  refers  to  the  set  of  data  elements  describing  an  OHMIS 
requirement,  i.e.,  the  set  of  data  element  types  included  in  OHMIS 
Requirement  Recommendation  Description  Data.  Although  the  file 
structure  for  OHMIS  has  not  been  determined  at  this  date,  it  may  be 
useful  to  think  of  Data  Sets  as  one  would  think  of  'records',  where  each 
data  element  type  on  a  Data  Set  represents  a  'field'  in  an  OHMIS 

1  record' . 

Section  6.6  contains  a  detailed  description  of  each  Data  Set  on  FIGURE 
6-3.  Much  of  the  content  of  how  the  OHMIS  system  will  operate  is 
contained  in  these  descriptions  of  Data  Sets.  These  descriptions 
provide  information  on  the  purpose  and  use  of  each  type  of  Data  Set,  how 
the  Data  Set  is  generated  or  entered  (i.e.,  the  Menu  Selection  Sequence 
for  entering  a  set  of  data  of  the  type  identified  by  the  Data  Set 
Number),  how  this  type  of  Data  Set  is  stored  and  deleted  from  the  OHMIS 
data  base,  etc. 


3)  Data  Lists.  This  terms  is  used  loosely  to  refer  to  a  series 
(i.e.,  multiple  entries)  of  sets  of  data  element  types  in  which  each 
of  the  sets  of  data  belong  to  the  same  data  element  type  or  the  same 
combination  of  data  element  types.  Functionally,  Data  Lists  are  used  in 
the  description  of  the  OHMIS  system  provided  in  this  report  as  'files’, 
i.e.,  multiple  entries  of  the  same  records.  However,  as  indicated 
above,  the  particular  file  structure  implied  in  the  use  of  Data  Lists  in 
this  report  should  not  be  assumed  to  be  the  final  determination  about 
the  OHMIS  file  structure,  but  rather,  a  convenient  means  of  describing 
the  organization  of  data  in  OHMIS  in  order  to  be  able  to  describe  the 
desired  characteristics  of  the  OHMIS  data  processing  functions.  FIGURE 
6-4  gives  the  Data  Lists  used  in  the  description  of  the  OHMIS  core  data 
processing  functions.  Many  of  these  files  serve  the  function  of 
indexes  to  the  rest  of  the  OHMIS  data  base,  i.e.,  to  the  Data  Sets,  in 
order  to  enable  quick  retrieval  of  the  data  with  a  specified  identifier. 

4)  Outputs.  FIGURE  6-5  provides  a  list  of  the  Outputs  described  in 
this  report.  Each  of  these  Outputs  is  described  in  detail  in  Section 
6.7.  The  descriptions  include  a  mock-up  of  each  Output  and  the  ?urce 
for  each  of  the  data  elements  in  the  Output.  As  indicated  above,  these 
are  the  generic  outputs  used  in  the  management  of  the  OHMIS  system. 
Specific  outputs  covering  a  given  set  of  data  are  not  given  in  this 
report,  because  this  would  serve  only  to  repeat  the  detailed  descrip¬ 
tions  of  the  Data  Sets  given  and  because  the  exact  contents  of  the  data 
entered  (and,  therefore,  the  exact  contents  of  the  outputs)  will  depend 
on  the  specifics  of  the  forms  specified  by  OHMIS  users. 

5)  Functional  Data  Flows  or  Functions.  FIGURE  6-6  provides  a  list 

of  the  titles  and  numbers  of  the  OHMIS  functions  described  in  detail  in 
this  report.  These  11  functions  have  been  grouped  into  four  groups. 

Each  Functional  Data  Flow  description  begins  with  a  document  summarizing 
the  function.  This  is  followed  by  a  description  of  each  data  processing 
step  in  the  function.  The  description  of  each  data  processing  step 
includes: 

o  A  description  of  the  step; 

o  The  previous  step  that  led  to  this  step; 

o  The  Inputs  to  the  step.  These  include: 

The  Menu  Selection  Sequence  (if  any)  which  the  user 
uses  to  arrive  at  this  step  in  the  OHMIS  program  and 
the  user  Input  Sequence  associated  with  the  Menu 
Selection  Sequence. 

o  The  Data  Retrievals  (i.e.,  retrievals  from  the  OHMIS  data 
base)  made  by  the  program  to  obtain  the  appropriate  data 
elements  for  conducting  the  processing  involved  in  the  step; 

o  The  specific  Data  Processing  involved  in  the  step; 

o  The  Outputs  generated  during  the  step,  if  any,  including  the 

new  Data  Sets  generated  by  the  OHMIS  program  as  a  part  of  the 
step. 
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FIGURE  6-3 


Data  Set  Number 
DS1 

DS2 

DS3 

DS4 

DS5 

DS6 

DS7 

DS8 

DS9 

DS10 

DS11 

DS12 

DS13 

DS14 

DS15 

DS16 

DS17 

DSI8 


TITLES  OF  DATA  SETS 


Data  Set  Title 

OHMIS  requirement  (recommendation) 
description  data  (see  ID6) 

Requirements  check  request  data  (see  IDl) 

(Information  triggered)  requirements  appli¬ 
cability  data  (see  ID5) 

Requirements  suspense  data  (i.e.,  date 
triggered  requirements  applicability  data), 
including  reminder  notice  data  (see  ID5) 

Requirements  implementation  data  (see  ID9) 

Triggering  step  requirement  implementation 
unit  identifier  types  data 

Data  element  type  information 

Values  data  for  requirement  applicability 
characteristics 

Current  user/position  identity  and  address 
data 

Forms  description  data  (see  ID16) 

Forms  subpart  data  (see  ID17) 

Forms  applicability  factors  data 

Forms  applicability  values  data  (see  ID19) 

Completed  forms  data  (see  ID18)  [generic  de¬ 
scription] 

Allowable  limits  applicability  factors  data 

Allowable  limits  applicability  values  data 
(see  ID20) 

Allowable  limits  specification  data  (see 
ID5 ) 

Allowable  limits  check  request  data  (see 
1022) 
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FIGURE  6-3  (Cont'd.) 


Data  Set  Number 
DSI9 

DS20 

DS21 

DS22 

DS23 
OS  24 
DS25 
DS26 

DS27 

DS28 


Data  Set  Title 

Missing  data  element  information  (see  ID21 
and  DL25 ) 

Time  period  specification  data  (see  ID24). 

Allowable  limits  table  data  (see  ID25) 

Outstanding  (uncompleted)  forms  monitoring 
data 

Task  description  data  (see  CT8) 

Specific  task  scheduling  data  (see  ID23) 

Facility  data  by  task  type  (CT8) 

Regular  weekly  schedule  availability  data 
(see  ID28) 

Monthly  schedule  data  (availability  and  use) 
Contact  and  location  data  (see  ID26) 


1 


FIGURE  6-4 


TITLES  OF  DATA  LISTS 


Data  List  Number 
DLl 
DL2 
DL3 

0L4 


Data  List  Title 

Vacant  job  class  list  (see  06) 

Potential  new  hire  list  (see  07) 

Outstanding  requirements  list  (ID9)  by  OHMIS 
service  area  (ID10)  (see  04) 

New  hire  list  (see  08) 


DL5 

DL6 

DL7 


List  of  requirements  applicability  charac¬ 
teristics  for  which  values  are  missing 

OHMIS  user/position  identifier  (ID  13/ 1 D 14 ) 
by  OHMIS  service  area  ( 1010 )  list 

OHMIS  user  identifier  (ID13)  by  password 
list 


DL8 

DL9 

OLIO 

DLll 

DL 12 

DL 13 

DL14 


OHMIS  user/position  identifier  (ID13/ID14) 
by  OHMIS  user/position  type  (CT1/CT2)  list 

Reminder  notice  list  (ID9  and  ID5)  by  OHMIS 
service  area  ( ID10) 

List  of  active  requirement  application  iden¬ 
tifiers  (ID5)  for  information  triggered  re¬ 
quirements  applicability  data  (DS3)  by 
triggering  step  (ID2)  and  by  OHMIS  service 
area  (ID10) 

List  of  active  requirement  application  iden¬ 
tifiers  (ID5)  for  requirement  suspense  data 
(0S4)  by  OHMIS  service  area  (ID10) 

List  of  requirements  check  request 
identifiers  (ID1)  by  OHMIS  service  area 
( ID10) 

List  of  active  form  specification  identifiers 
(ID16)  by  form  type  (CT9)  and  by  OHMIS  ser¬ 
vice  area  (ID10) 

List  of  active  (allowable  limits  specifica¬ 
tion)  requirement  application  identifiers 
(ID5)  by  forms  subpart  identifier  (ID17)  and 
OHMIS  service  area  ( I D 10 ) 


FIGURE  6-4  (Cont'd.) 


Data  List  Number 
DL 15 

0L16 

DL17 

0L18 

DL19 

DL20 

DL21 

DL22 

DL23 


Data  List  Title 


List  of  active  allowable  limits  application 
identifiers  (ID20)  by  forms  subpart  identi¬ 
fier  (ID17)  and  by  OHMIS  service  area  (IDIO) 

List  of  active  (allowable  limits  specifica¬ 
tion)  requirement  application  identifiers 
( ID5 )  by  active  allowable  limits  application 
identifier  (ID20)  and  by  OHMIS  service  area 
(IDIO) 

List  of  allowable  limits  check  request  iden¬ 
tifiers  (ID22)  by  completed  form  identifier 
(ID18)  and  by  OHMIS  service  area  (IDIO) 

List  of  active  (allowable  limits  specifica¬ 
tion)  requirement  implementation  identifiers 
( ID9)  by  completed  form  identifiers  (ID18) 
and  OHMIS  service  area  (IDIO) 

List  of  all  active  allowable  limits  table 
data  (DS21)  for  a  given  allowable  limits 
table  identifier  (ID25) 

List  of  the  active  default  (allowable  limits 
specification)  requirement  application  iden¬ 
tifiers  (ID5)  by  the  forms  subpart  identi¬ 
fier  (ID17)  and  by  the  OHMIS  service  area 
(IDIO) 

List  of  the  active  default  forms  specifica¬ 
tion  identifier  (ID16)  by  the  form  type  code 
(CT9)  and  OHMIS  service  area  (IDIO) 

List  of  active  allowable  limits  application 
identifiers  (ID20)  by  forms  specification 
identifier  (ID16)  and  by  OHMIS  service  area 
(IDIO) 

Current  forms  list 


DL24 

DL25 


List  of  form  application  identifiers  (ID19) 
by  form  type  code  (CT9)  and  OHMIS  service 
area  (IDIO) 


Missing  data  element  list  (see  DS19) 


f 


I 
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FIGURE  6-4  (Cont'd.) 


Data  List  Number 
DL26 

DL27 

DL28 

DL29 

DL3U 

DL31 

DL32 


DL33 

DL34 

DL35 


Data  List  Title 


List  of  new  outstanding  data  requests  (ID18) 
(not  overdue)  by  OHMIS  service  area  (ID10) 

List  of  outstanding  data  requests  (ID18)  (no 
due  date  specified)  by  OHMIS  service  area 
(ID10) 

List  of  overdue  data  requests  (ID18)  by  OHMIS 
service  area  (ID10) 

List  of  active  (allowable  limits  specifica¬ 
tion)  requirement  application  identifiers 
(ID5)  by  forms  specification  identifier 
(ID16)  and  OHMIS  service  area  (ID10) 

List  of  active  default  (allowable  limits 
specification)  requirement  application 
identifiers  (ID5)  by  forms  specification 
identifier  (ID16)  and  OHMIS  service  area 
( ID10 ) 

List  of  task  identifiers  (ID23)  for  tasks 
that  cannot  be  scheduled  by  OHMIS  service 
area  (ID10) 

List  of  the  employee  identifier  (ID4)  that  is 
one  of  the  requirement  implementation  units 
with  the  corresponding  requirement 
application  identifier  (ID5)  and  OHMIS 
service  area  identifier  (ID10),  for  those 
ID5s  that  identify  requirement  suspense  data 
sets  (DS4)  that  will  trigger  an  'employee 
transport'  type  of  task 

List  of  monthly  schedule  identifiers  (ID27) 
by  OHMIS  service  area  (ID10) 

List  of  qualified  employee  identifiers  (ID4) 
by  task  type  (CT8)  and  by  OHMIS  service  area 
( IDlO) 

List  of  requirement  implementation 
identifiers  (ID9)  for  requirements  having 
tasks  that  need  to  be  scheduled  by  OHMIS 
service  area  ( IDlO) 
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FIGURE  6-4  (Cont'd.) 


Data  List  Number 
DL36 

DL3/ 

DL38 

DL39 

DL40 

DL41 

DL42 

DL43 

DL44: 


Data  List  Title 


List  of  requirement  implementation  units 
(or  sets  of  units)  linked  to  their 
corresponding  task  identifier  (ID23),  OHMIS 
service  area  identifier  (ID1Q)  and  whether 
the  task  is  an  'employee  transport1  type  of 
task 

List  of  the  task  identifier  (ID23)  by  the 
main  facility  identifier  (ID8)  in  which  the 
task  will  take  place  and  by  its  OHMIS 
service  area  (ID10) 

List  of  task  identifiers  (ID23)  by  require¬ 
ment  implementation  identifier  (ID9)  and  by 
OHMIS  service  area  ( I  DIO ) 

List  of  task  identifiers  (ID23)  for  tasks 
that  need  to  be  rescheduled  by  OHMIS  service 
area  (ID10) 

List  of  weekly  schedule  identifiers  (1028)  by 
employee  identifier  (ID4)  and  by  OHMIS  service 
area  (ID10) 

List  of  the  monthly  schedule  identifiers 
(ID27)  for  an  OHMIS  service  area  (ID10)  with 
the  corresponding  year  and  month  covered  by 
the  monthly  schedule  data  (DS27)  identified  by 
the  ID27  and  the  employee  identifier  (ID4)  of 
the  employee  performing  the  task  scheduled  on 
this  DS27  data 

List  of  the  contact  identifier  (ID26)  by  the 
identifier  of  the  person  or  thing  for  which 
contact  and  location  data  (DS28)  is  provided, 
by  OHMIS  service  area  (ID10) 

List  of  weekly  schedule  identifiers  (1028)  by 
contact  identifiers  (1026)  and  by  OHMIS  service 
area  ( I  DIO ) 

Menu  Selection  Sequence  by  OHMIS  user  type 
code  (CT1) 
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FIGURE  6-5 


Output  Number 
01 
02 
03 

04 

05 

06 

07 

08 

09 

010 

Oil 

012 

013 

014 

015 

016 

017 


TITLES  OF  OUTPUTS 


Output  Title 

Requirements  Check  Notice 

Outstanding  Requirements  Checks  Needed  List 

Requirements  Notification  and  Certification 
Record 

Outstanding  Requirements  List  (see  DL3) 

Reminder  Notice  List  (see  DL9) 

Vacant  Job  Class  List  (see  DL1) 

Potential  New  Hire  List  (see  D12) 

New  Hire  List  (see  DL4) 

Allowable  Limits  Check  Notice 

Outstanding  Allowable  Limits  Checks  Needed 
List 

Allowable  Limits  Evaluation  Surrmary 

OHMIS  'Blank'  Form  (see  Form  Types)  [Generic 
Description  of  All  OHMIS  'Blank'  Forms] 

Outstanding  Data  Requests  List  (see  DL27  and 
DL28) 

Daily  Schedule 
Scheduling  Notice 
Scheduled  Task  Description 
List  of  Unscheduled  Tasks 
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FIGURE  6-6 

TITLES  OF  OHMIS  CORE  DATA  PROCESSING  FUNCTIONS 


FUNCTION  FI:  User  Transparent  Functions 

Function  F1A:  ‘Log-on*  Transparent  Function 

Function  FIB:  Triggering  Step  Transparent  Function 

FUNCTION  F2:  Requirements  Functions 

Function  F2A:  Requirements  Check  Function 

Function  F2B:  Function  for  Entering  Requirements  Disposition 
Data 


FUNCTION  F3:  OHMIS  Forms  Data  Processing  Functions 

Function  F3A:  Generation  of  (Blank)  Forms  Functions 

Function  F3B:  Completed  Forms  Data  Entry  and  Allowable  Limits 
Evaluation  Function 

Function  F3C:  Allowable  Limits  Check  Function 

Function  F3D:  Function  for  Canceling  the  Monitoring  of  Outstand¬ 
ing  (uncompleted)  OHMIS  Forms 

FUNCTION  F4:  Scheduling  Functions 

Function  F4A:  Scheduling  Function 

Function  F4B:  Rescheduling  Function 

Function  F4C:  Function  for  Routine  Generation  of  Tentative 
Monthly  Schedule  Availability  Data 
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The  Functional  Data  Flows  thus  provide  the  IPOs  for  the  core  OHMIS  data 
processing  functions.  A  description  of  these  core  functions  is  provided 
in  the  Section  below. 

6.3  FOUR  TYPES  OF  DATA  IN  THE  OHMIS  CORE  DATA  PROCESSING 
FUNCTIONS 

In  this  Section  each  of  the  four  basic  types  of  data  required  to  perform 
the  assurance  management  functions  of  OHMIS  are  described. 

As  indicated  in  Section  V,  the  overall  assurance  management  function  of 
OHMIS  is  to  assure  that  the  requirements  for  an  Occupational  Health 
Program  are: 

1)  Triggered,  i.e.,  the  occasions  in  which  the  requirements 
apply  are  routinely  identified  by  all  levels  of  DA 
Occupational  Health  Program  managers;  and,  are 

2)  Monitored,  i.e.,  the  implementation  of  the  requirements 
are  routinely  monitored  until  complete  and  evaluated 
compared  to  DA  performance  criteria. 

To  achieve  these  two  assurance  management  functions,  OHMIS  must 
contain  the  following  generic  types  of  information: 

1)  Specification  for  requirements,  i.e.,  information  on  the 
exact  nature  and  content  of  each  requirement  for  the 
operation  of  the  DA  Occupational  Health  Program. 

2)  Specifications  on  the  applicability  of  the  requirements, 
i.e.,  information  on  the  conditions  or  circumstances  under 
which  the  requirements  apply.  The  OHMIS  data  base  must 
also  contain  information  on  the  current  status  of  the 
Occupational  Health  Program  in  order  to  determine  if  the 
current  conditions  or  circumstances  match  those  for  which 
requirements  apply,  i.e.,  to  determine  if  a  requirement 
should  be  triggered. 

3)  Requirements  implementation  data,  i.e.,  data  to  monitor 
the  status  of  a  requirement  until  it  is  executed  and  to 
store  the  history  of  requirements  that  have  been  implemented 
in  order  to  audit  the  DA  Occupational  Health  Program. 

4)  Scheduling  data,  i.e.,  data  to  schedule  the  execution  of  a 
task  specified  by  a  requirement  that  has  been  triggered. 

Each  of  these  four  basic  types  of  information  are  discussed  below. 

6.3.1  OHMIS  Requirements  Data 

In  the  OHMIS  core  data  processing  programs,  a  requirement  for  the  DA 
Occupational  Health  Program  defined  in  the  OHMIS  requirements 
( recommendations)  description  data  set  (DS1).  Requirements  are  of  many 
types.  There  will  of  course  be  many  requirements  based  on  OSHA-type 
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regulations.  These  requirements  will  include  the  corrective  actions 
that  must  be  taken  to  address  specific  hazards.  There  will  also  be 
requirements  for  monitoring  hazards,  e.g.,  the  frequency  of  Industrial 
Hygiene  Surveys,  and  for  monitoring  exposures  to  hazards,  e.g.,  the 
frequency  of  medical  surveillance.  These  types  of  requirements,  based 
on  regulations,  have  been  discussed  elsewhere  in  this  report  and  are  not 
reiterated  here.  Not  all  requirements  in  the  OHMIS  data  base  must  be 
derived  from  regulations,  however.  Requirements  can  be  either 
mandatory  or  recommended,  i.e.,  based  on  best  judgement,  but  not 
required  in  regulations. 

Some  types  of  requirements  will  be  based  on  experience  rather  than 
regulations.  For  example,  the  investigation  of  a  particular  mishap, 
such  as  the  spill  of  a  hazardous  substance,  may  result  in  corrective 
actions  that  are  determined  to  apply  to  other  circumstances .  These  then 
may  become  requirements  that  are  initiated  whenever  the  identified 
circumstances  occur.  One  of  the  purposes  of  the  OHMIS  system  is  to 
capture  these  "lessons  learned"  from  past  experience  and  ensure  that  the 
lessons  are  applied  in  the  future.  Requirements  can  also  be  based  on 
reviews  of  literature  or  on  expert  opinion.  The  OHMIS  system  does  not 
stipulate  that  a  requirement  must  be  based  on  a  regulation  or  that  the 
corrective  actions  recommended  in  a  requirement  have  proven 
effectiveness.  The  OHMIS  requirement  description  data  (DS1)  provides 
for  the  storing  of  information  on  the  source  and  rationale  of  a 
requirement  or  recommendation,  including  references  to  mishap  reports, 
literature,  regulations,  special  studies,  etc.  Some  of  the  requirements 
entered  into  the  OHMIS  data  base  will  be  requirements  to  provide  a 
certain  type  of  data.  For  examole,  there  may  be  a  requirement  to  update 
a  civilian  employee's  medical  history  data  periodically,  i.e.,  to  update 
the  data  on  diagnoses  and  treatments  received  outside  of  the  DA  medical 
service.  These  types  of  requirements  for  entering  information  into  the 
OHMIS  data  base  are  included  in  the  requirements  data  (DS1)  for  two 
purposes:  to  provide  a  means  of  triggering  the  actions  needed  for 
(i.e.,  to  assure  that) : 

1)  The  integrity  of  the  OHMIS  data  base  is  maintained,  i.e., 
assure  that  all  needed  data  is  entered,  is  current  and  that 
quality  control  checks  for  accuracy  have  been  made;  and 

Z)  All  information  needed  to  determine  the  applicability  of  the 
requirement  is  obtained.  For  example,  if  there  is  a 
requirement  that  applies  to  an  employee  only  if  the  employee 
is  over  age  50,  then,  in  order  to  assure  that  the 
requirement  is  triggered  whenever  an  employee  with  this 
characteristic  is  identified,  the  OHMIS  data  base  must  have 
a  requirement  specifying  that  the  age  of  all  enployees  be 
entered.  The  core  OHMIS  data  processing  functions  provide 
for  the  identification  of  missing  data  elements  and  the 
'automatic'  generation  of  forms  for  collecting  these  missing 
va  1  ues . 

In  the  examples  given  above,  all  of  the  requirements  specify  that 
certain  actions  be  undertaken,  e.g.,  whenever  a  certain  hazard  is 
identified  a  certain  (corrective)  action  is  implemented.  This  is  the 


only  type  of  requirement  that  is  specified  in  the  OHMIS  requirements 
description  data  (DS1).  There  is,  however,  another  type  of  requirement 
that  specifies  the  content  of  an  occupational  health  program  activity. 
For  example,  a  requirement  that  the  medical  examination  for  employees  in 
certain  job  classes  include  a  hearing  test  prescribes  the  content  of 
the  medical  examination. 

In  the  OHMIS  core  programs  this  type  of  nonaction  requirement  is  called 
a  con  tent- spec  if i cat  ion  requirement  to  distinguish  it  from  the 
action-type  requirement.  Content-specification  requirements  are  handled 
through  Forms  Description  Data  (DS10),  rather  than  through  requirements 
description  data  (DS1).  In  the  forms  description  data  (DS10)  the  OHMIS 
user  prescribes  the  content  of  an  OHMIS  data  entry  form,  i.e.,  what 
data  element  types  be  included  in  the  form,  and  thereby  prescribes  the 
content  of  the  OHMIS  activity  documented  by  the  completion  of  that 
form.  In  the  above  example,  the  OHMIS  user  can  specify  the  content  of 
the  occupational  activity  of  conducting  a  routine  medical  exam  by 
specifying  the  information  that  needs  to  be  collected  on  the  medical 
examination  form  used  for  this  activity.  Similarly,  the  requirements 
for  the  content  of  an  Industrial  Hygiene  survey  (e.g.,  what  measurements 
are  to  be  taken)  can  be  prescribed  by  specifying  the  contents  of  the 
Industrial  Hygiene  survey  form. 

Normally,  for  a  given  occupational  health  activity  there  will  be  both 
requirements  description  data  (DS1)  and  forms  description  data  (DS10) 
covering  both  the  action-type  requirements  and  the  content-specification 
type  requirements.  For  example,  the  triggering  of  the  action  of 
undertaking  a  routine  medical  exam  (i.e.,  the  requirements  for  the 
frequency  of  medical  surveillance)  is  accomplished  through  DS1  data  as 
is  the  requirement  for  the  action  of  using  a  specific  sampling  procedure 
in  an  Industrial  Hygiene  survey.  Also,  the  DS1  data  (and  the 
corresponding  task  (action)  type  description  data  (DS23))  includes 
prescriptions  for  the  type  of  OHMIS  user/position  that  is  to  conduct  an 
action,  e.g.,  who  is  considered  qualified  to  perform  ;  medical  exam  or 
an  Industrial  Hygiene  survey. 

OHMIS  requirements  may  be  specified  at  any  level  ranging  from  the 
USAtHA  to  the  local  OA  installation.  However,  in  most  instances,  it 
will  be  the  differences  in  the  appl icabi 1 i ty  of  a  requirement  that 
will  be  determined  at  a  local  level,  while  the  requirements  themselves 
(including  the  specific  contents  of  forms)  will  be  prescribed  at  the 
DA  level.  The  D51  data  includes  a  specification  as  to  the  type  of 
organizational  level  at  which  the  requirement  is  to  apply,  but  it  is 
up  to  each  OHMIS  service  area  to  generate  specific  requirements 
applicability  data  that  will  trigger  the  implementation  of  the 
requirement  in  their  OHMIS  service  area.  The  USAtHA,  however,  may 
review  and  modify  the  requirements  applicability  data  specified  at  a 
local  level  at  any  time. 

6.3.2  Requirements  Applicab i  1_ i ty__D a t  a _  The  UHM I_S  Requirement 
Triggering  Mechanism 

A  fundamental  assurance  management  function  of  the  core  OHMIS  data 
processing  program  is  to  trigger  action  type  requirements.  That  is, 
the  OHMIS  programs  ' an  tom  r  :  a  1 1 y‘  : 


o  Determine  that  the  conditions  or  circumstances  in  which  a 
requirement  applies  have  occurred; 

o  Notify  the  OHMIS  user  of  the  need  for  the  requirement;  and, 

o  Generates  the  requirements  implementation  data  (DS5)  and  the 
scheduling  data  needed  to  monitor  the  requirement  until  the 
user  indicates  that  the  requirement  has  been  executed. 

There  are  three  ways  in  which  a  requirement  may  be  triggered  in  the 
OHM  IS  system.  The  specifications  for  when  a  requirement  is  determined 
to  be  appl icable  (i.e.,  when  it  is  to  be  triggered)  for  each  of  these 
three  types  of  'triggers'  are  given  in  three  different  types  of 
requirements  applicability  data,  named  for  the  type  of  conditions  or 
circumstances  under  which  the  requirement  applicability  data  is  used: 

1)  Information  triggered  requirements  applicability  data  (DS3). 
This  data  set  is  used  to  trigger  a  requirement  whenever  a  user 
executes  a  data  processing  step  in  the  OHMIS  program  that  has 
been  designated  as  a  triggering  step.  Whenever  the  user 
enters  data  onto  the  OHMIS  data  base  using  a  data  processing 
step  that  has  been  designated  as  a  triggering  step,  the  OHMIs 
triggering  step  program  (Function  FIB)  compares  the  values 
entered  or  the  previously  entered  values  for  the 

character isti cs  of  the  identifier  entered  during  the 
triggering  step  with  the  value  specified  in  the  sets  of  DS3 
data  for  the  triggering  step.  If  a  match  is  found,  the 
requirements  specified  in  the  matching  DS3  data  is  triggered, 
i.e.,  requirements  implementation  data  (DS5)  for  that 
requirement  is  generated. 

2)  Date  triggered  requirements  applicability  data  (also  called 
requirements  suspense  data)  (DS4).  This  data  set  is  used 
to  trigger  a  requirement  whenever  a  certain  date  (specified 
on  the  DS4  data)  arrives.  The  DS4  data  can  specify  either  a 
specific  due  date,  for  one-time  requirements,  i.e.,  those 
that  are  to  be  implemented  only  once;  or,  an  interval  of 
time  that  will  be  used  by  the  OHMIS  program  to  generate  a 
series  of  due  dates  (e.g.,  once  every  two  years)  for 
periodically  triggered  requirements,  such  as  medical 
examinations  and  Industrial  Hygiene  surveys  that  are  to  be 
conducted  more  than  once  on  a  routine  basis.  The  type  of 
requirement  triggering  system  specified  in  the  DS4  data 
operates  in  a  manner  similar  to  a  'tickler'  (or  suspense) 
file  system.  Every  day  the  OHMIS  'log  on'  program  (Function 
F1A)  checks  to  determine  if  the  current  date  matches  a  due 
date  specified  in  a  set  of  DS4  data.  If  it  does,  the 
requirement  specified  in  the  DS4  data  is  generated. 

3)  Allowable  limits  specifications  triggered  requirements 
applicability  data  (DS17).  This  type  of  data  set  is  used 
to  specify  an  allowable  limit  for  a  given  type  of  data 
element.  Whenever  data  is  entered  onto  the  OHMIS  data  base 
from  an  OHMIS  form  (i.e.,  a  form  specified  by  the  user  on 


forms  description  data  (DS10)),  the  OHMIS  completed  forms 
data  entry  program  (Function  F3B)  identifies  the  sets  of 
0S17  data  that  are  applicable.  It  then  compares  the  values 
entered  from  the  form  with  the  specified  values  given  for 
that  data  element  type  on  each  set  of  applicable  DS17  data. 

If  they  match,  the  requirement  given  on  the  matching  DS17 
data  is  triggered. 

In  each  of  the  above  cases,  the  requirements  applicability  data  triggers 
an  action  type  requirement.  That  is  a  set  of  requirements 
implementation  data  ( DS5 )  is  generated  when  a  requirement  is  triggered 
and  this  0S5  data  is  used  to  monitor  the  execution  of  the  action 
specified  by  the  requirement.  For  content-specification  type 
requirements  (based  on  the  forms  description  data  ( DS10 ) ) ,  the 
appl icabi 1 ity  of  the  requirement  is  similar  but  determined  in  a 
different  manner.  When  the  OHMIS  user  wishes  to  generate  a  blank  OHMIS 
form  ( i . e . ,  Menu  Selection  Sequence  2.1.5)  the  OHMIS  forms  generation 
program  (Function  F3A)  asks  the  user  for  the  type  of  form  (CT9)  desired. 
The  program  the  identifies  what  factors  determine  the  appl icabi 1 i ty  of 
the  form  using  the  forms  applicability  factors  data  (DS12)  and  asks  the 
user  for  the  values  for  these  factors.  For  example,  which  medical 
examination  form  is  applicable  may  depend  on  the  job  class  of  the 
employee  being  examined.  In  this  case  the  job  class  would  be  an 
applicability  factor  determining  which  specification  of  the  form  should 
be  used.  When  the  user  enters  a  value  for  the  forms  applicability 
factor  ( i . e - ,  in  the  above  example  gives  a  job  classification 
identifier),  the  program  examines  all  sets  of  forms  appl icabi 1 ity  values 
data  (DS13)  for  the  form  type  until  a  value  is  found  that  matches  that 
entered  by  the  user.  The  form  specification  identifier  (ID16)  given  on 

the  set  of  DS13  data  which  is  found  to  match  the  value  given  by  the  user 

identifies  the  set  of  forms  description  data  (DS10)  that  defines  the 

version  of  the  form  that  is  to  be  used.  The  OHMIS  program  uses  this  set 

of  DSIO  data  to  generate  the  appropriate  version  of  the  form.  The  user 
is  thus  compelled  to  use  the  data  entry  form  that  meets  the 
content-specification  requirement,  i.e.,  in  this  case  the  user  is 
compelled  to  conduct  the  type  of  medical  examination  that  has  been 
determined  through  OHMIS  policy  (requirements)  to  be  appropriate  for  the 
job  class  of  the  employee  being  examined. 

6.3.3  Requirements  Implementation  Data 

Each  time  an  action  type  requirement  is  triggered  by  the  OHMIS  program, 
a  set  of  requirements  implementation  data  (DS5)  is  generated  by  the 
OHMIS  program  (i.e.,  the  user  does  not  enter  DS5  data).  The  data 
describes  the  requirements  to  be  implemented  and  identifies  the 
requirement  implementation  unit  '  '  this  execution  of  the  requirement. 
The  information  describing  the  requirement  is  obtained  from  the 
requirements  description  data  (DS1)  that  corresponds  to  the  requirement 
identifier  (106)  given  on  the  requirements  appl icabi 1 ity  data  (DS3,  DS4, 
or  0S17)  that  triggered  the  requirement.  The  requirement 
implementation  unit  is  the  person  or  thing  about  which  a  requirement  is 
to  be  implemented.  For  example,  if  a  set  of  DS4  data  triggered  a 
requirement  to  conduct  an  Industrial  Hygiene  survey  in  a  given  facility, 
the  facility  identifier  for  that  facility  would  be  the  requirement 
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implementation  unit  for  this  execution  of  the  requirement.  The 
identification  of  the  requirement  implementation  unit  for  a  particular 
execution  of  a  requirement  is  given  in  the  triggering  step  requirement 
implementation  unit  identifier  type  data  (DS6)  for  information  triggered 
requirements  ( DS 3 ) ;  in  the  0S4  data  triggering  the  requirement  for  date 
triggered  requirements;  and  in  the  identif ication  information  on  the 
form  being  entered  (referred  to  as  the  forms  unit  information  for  the 
form)  which  contained  the  data  element  type  for  which  an  allowable  limit 
was  found  to  have  been  met,  for  allowable  limits  triggered  requirements 
(DS17) . 

Each  day  as  a  part  of  the  'log-on'  program  (Function  F1A),  the  OHMIS 
program  informs  the  user  of  all  outstanding  (not  executed)  requirements 
using  the  Outstanding  Requirements  List  (Output  04).  The  user  employs 
the  requirement  implementation  identifier  (1D9)  on  this  list  to  generate 
a  detailed  description  of  each  outstanding  requirement.  This  detailed 
description  is  given  on  the  Requirements  Notification  Identification 
Record  (Output  03).  This  document  informs  the  user  about  the  details  of 
the  requirement  and  provides  a  data  entry  space  for  entering  information 
on  the  disposition  of  the  requirement.  There  are  four  types  of 
dispositions  of  requirements:  1)  fully  completed,  2)  partially 
completed,  3)  aborted  (i.e.,  decided  not  to  complete),  and  4)  determined 
to  be  not  applicable  for  this  particular  execution  of  the  requirement. 
The  DS1  data  on  the  requirement  specifies  what  types  of  dispositions  of 
a  requirement  are  acceptable  and  what  types  of  approvals  of  the 
disposition  are  required. 

The  information  about  the  disposition  of  a  requirement  is  stored  on  the 
requirements  implementation  data  (DS5)  for  the  requirement.  Every 
effort  has  been  made  to  design  the  OHMIS  core  programs  to  provide  a 
mechanism  for  carefully  documenting  the  implementation  of  requirements 
and  for  storing  this  information  permanently.  Historical  DS5  data, 
i.e.,  DS5  data  on  the  requirements  that  have  already  been  executed,  is 
maintained  in  the  OHMIS  data  base.  Provision  is  made  for  retaining  the 
hard  ccpy  of  the  Requirements  Notification  and  Certification  Record  for 
a  requirement  so  that  the  signatures  of  those  persons  who  executed  and 
approved  the  execution  of  the  requirement  may  be  retained,  if  desired. 

It  is  not  possible  to  delete  a  requirement  from  the  Outstanding 
Requirements  List  (0L3;  04)  or  delete  a  task  from  the  OHMIS  monthly 
schedule  of  tasks  (Output  014)  without  formal  documentation  of  the 
disposition  of  the  requirement.  This  formal  documentation  process  is 
embodied  into  the  OHMIS  core  data  processing  functions  in  order  to 
provide  an  'audit  trail'  for  all  DA  Occupational  Health  Program 
activities.  The  OHMIS  data  base  will  provide  a  record  of  all  hazards 
identified  and  decisions  made  about  all  corrective  actions  identified 
and  implemented  for  these  hazards.  This  will  enable  the  type  of 
epidemiological  correlation  studies  mentioned  previously,  i.e.,  the 
correlation  of  medical  events  to  the  hazards  to  which  employees  are 
exposed  and  the  corrective  actions  used  for  these  hazards.  More 
immediately,  this  documentation  process  enables  each  OHMIS  service  area 
to  be  routinely  monitored  for  the  specific  tasks  that  are  being  executed 
as  as  part  of  their  Occupational  Health  Program.  An  evaluation  can  be 
made  of  the  degree  to  which  each  OHMIS  service  area  is  following  the 
guidelines  for  operation  of  a  DA  Occupational  Health  Program,  i.e,  the 
operating  policies  and  goals  specified  in  the  OHMIS  requirements. 
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6.3.4  QHMIS  Scheduling  Data 

As  indicated  above,  requirement  description  data  (DS1)  describes  action 
type  requirements,  i.e.,  requirements  prescribing  a  particular  task 
that  should  be  undertaken  in  order  to  operate  the  DA  Occupational  Health 
Program  according  to  the  policies  and  goals  specified  by  the  Department 
of  the  Army.  Many  of  these  actions  will  be  ' scheduleable'  tasks,  i.e., 
tasks  for  which  it  is  possible  to  estimate  the  amount  of  time  and  the 
persons  needed  to  perform  the  task.  If  the  requirement  is  for  a 
'scheduleable  task',  a  task  type  code  (CT8)  is  given  on  the  requirements 
description  data  (DSI).  Whenever  requirements  corresponding  to  this  DS1 
data  are  triggered,  i.e.,  whenever  requirements  implementation  data 
(DS5)  is  generated  for  a  requirement  for  which  the  requirements 
description  data  (DSI)  specifies  a  task  type  code  (CT8),  the  QHMIS 
scheduling  program  (Function  F4A)  schedules  a  task  of  the  type  specified 
in  the  DSI  data.  For  example,  if  a  requirement  to  conduct  a  routine 
medical  exam  for  an  employee  were  triggered,  the  OHMIS  scheduling 
program  would  automatically  schedule  this  task  as  soon  as  the 
requirement  has  been  triggered. 

In  order  to  automatically  schedule  tasks,  the  OHMIS  core  data  base 
contains  information  on  the  availability  of  each  OHMIS  user/position  who 
is  available  for  scheduling  for  each  day  of  the  week.  This  data  is 
contained  in  a  regular  weekly  schedule  availability  data  (DS26).  Using 
the  characteristics  of  the  task  type  given  on  the  task  type  description 
data  (DS23)  and  the  list  of  qualified  employee  identifiers  by  task  type 
(DL34),  the  scheduling  program  determines  the  priority  of  each  task  and 
the  persons  available  to  perform  the  task  and  schedules  the  task 
accordingly.  The  schedule  is  stored  on  the  monthly  scheduled  data 
(DS27).  For  those  tasks  requiring  it,  a  Scheduling  Notice  (Output  015) 
is  automatically  generated  for  the  task.  This  is  sent  by  the  OHMIS  Data 
Processing  staff  person  to  the  person  participating  in  the  task,  e.g., 
the  employee  participating  in  the  medical  exam. 

Every  day  as  a  part  of  the  ’log-on’  program  (Function  F1A)  the  program 
generates  a  Daily  Schedule  (Output  014)  for  each  OHMIS  user/position 
indicating  the  schedule  of  tasks  for  that  user/position  for  that  day. 

A  scheduled  task  description  (016)  for  each  task  is  also  generated. 

This  output  describes  the  task  in  detail.  It  is  generated  from  the 
specific  task  scheduling  data  (DS24)  for  the  task.  Included  on  this 
output  are  problems  with  scheduling  the  task.  This  information  can  be 
used  by  each  OHMIS  service  area  to  evaluate  whether  a  change  in  the 
scheduling  availability  data  (DS26)  is  warranted,  i.e.,  whether  the  time 
resources  allocated  to  each  time  of  task  on  the  DS26  data  are  adequate 
and  consistent  with  the  mix  of  tasks  being  triggered  for  the  OHMIS 
service  area. 

The  user  indicates  that  a  task  has  been  completed  by  entering  the 
requirement  disposition  data  on  the  requirement  for  which  the  task  was 
initiated  (i.e.,  by  completing  the  Requirements  Notification  and 
Certification  Records  (Output  03)  and  entering  this  disposition  data 
onto  the  requirements  implementation  data  (DS5)  for  the  requirement). 
Only  after  this  formal  process  of  complying  with  requirement  is  the 
requirement  removed  from  the  schedule.  Each  day  as  a  part  of  the 
'log-on'  function  (Function  FlA)  the  OHMIS  program  determines  if  more 
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than  one  week  has  passed  since  a  task  was  scheduled  for  completion.  If 
it  has  and  the  specific  task  scheduling  data  (DS24)  for  the  task  has  not 
been  deleted  (i.e.,  the  disposition  data  on  the  requirement  which 
initiated  the  task  has  not  been  entered)  the  task  is  rescheduled 
(Function  F4B). 

6.4  OHMIS  CORE  DATA  PROCESSING  FUNCTIONS 


To  summarize  the  above  discussion,  we  will  conclude  by  reviewing  each  of 
the  11  OHMIS  core  data  processing  functions  listed  in  FIGURE  6-6.  These 
11  functions  have  been  classed  into  4  groups  of  Functions. 

FUNCTION  1,  the  User  Transparent  Functions,  provide  for  the  processing 
of  those  functions  that  happen  'automatically'  without  the  users 
initiation.  These  include  Function  F1A,  the  'log-on'  transparent 
function  which  is  executed  each  time  someone  logs  onto  the  OHMIS  system. 
This  function  compares  the  current  date  with  the  due  date  triggered 
requirements  applicability  data  (DS4)  and  triggers  that  all  requirements 
that  have  come  to  by  the  current  date.  It  also  identifiers  which  tasks 
need  to  be  scheduled.  Function  F1A  also  generates  the  daily  list  of 
Outstanding  Requirements  (Output  04)  and  the  Daily  Schedule  (014)  as 
well  as  other  routine  data  processing  outputs,  such  as  the  list  of 
outstanding  data  requests  (Output  013)  which  tells  the  OHMIS  service 
area  which  forms  have  been  sent  out  and  are  due  back. 

Function  FIB,  the  triggering  step  transparent  function,  executes  the 
'automatic'  check  for  information  triggered  requirements  (i.e.,  reviews 
the  DS3  data)  that  occurs  each  time  a  user  executes  a  triggering  step  in 
the  OHMIS  programs. 

FUNCTION  2,  the  Requirement  Functions,  has  three  types  of 
subfunctions.  Function  F2A,  the  requirements  check  function,  provides 
a  means  for  the  user  to  execute  a  check  for  information  triggered 
requirements,  i.e.,  to  check  the  DS3  data  to  determine  if  a  requirement 
is  applicable.  This  check  is  done  whenever  the  current  OHMIS  data  base 
does  not  have  sufficient  information  to  'automatically'  determine  if  an 
information  triggered  requirement  is  applicable.  This  would  be  the 
case,  if  the  applicability  factors  provided  in  the  DS3  data  to 
determine  whether  or  not  a  requirement  is  applicable  were  factors  for 
which  the  current  OHMIS  data  base  does  not  have  values.  The  user  is 
notified  daily  on  the  Outstanding  Requirements  Checks  Needed  List 
(Output  02)  (generated  in  Function  F1A)  of  those  requirements  that 
require  manual  entry  of  values  for  the  applicability  factors  in  order  to 
determine  if  requirements  are  applicable. 

Function  F2B,  the  function  for  entering  requirements  disposition  data, 
provides  the  program  for  entering  data  on  the  execution  of  a 
requirement,  i.e.,  the  date  and  type  of  disposition  on  the  requirement, 
who  executed  and  approved  the  requirement,  the  location  of  further 
information  on  the  execution  of  the  requirement,  etc.  This  data  is 
entered  onto  the  requirements  implementation  data  (DS5)  for  the 
requirement.  When  this  data  is  entered,  Function  F2B  of  the  OHMIS 
program  deletes  the  requirement  from  the  outstanding  requirements  list 
(DL3;  Output  04)  and  deletes  the  specific  task  scheduling  data  (DS24)  on 
the  task  initiated  by  the  requirement  from  the  OHMIS  data  base. 
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FUNCTION  3,  the  OHMIS  Forms  Data  Processing  Function,  includes  three 
subfunctions.  Function  F3A,  the  generation  of  'blank'  forms  function, 
uses  the  forms  description  data  (DS10)  to  generate  a  form  of  the  form 
type  specified  by  the  user  that  meets  the  forms  appl icabi 1 ity  values 
specified  by  the  user.  This  function  identifies  and  implements  the 
content-specification  type  of  requirements  for  the  OHMIS  program. 

Output  02  provides  a  generic  description  of  all  OHMIS  blank  forms. 

Function  F3B,  the  completed  forms  data  entry  and  allowable  limits 
evaluation  function,  provides  a  means  for  the  user  to  enter  data  from  an 
OHMIS  form,  i.e.,  to  enter  the  completed  forms  data  generically  defined 
for  all  forms  in  the  DS14  data  set.  This  function  also  'automatically' 
evaluates  the  data  entered  on  the  OHMIS  forms  to  determine  if  it  matches 
the  allowable  limits  specified  in  the  0S17  data  and  triggers  the 
applicable  requirements  implementation  data  (DS5)  for  those  requirements 
specified  in  sets  of  DS17  data  for  which  allowable  limit  were  to  found 
to  match. 

Function  F3C,  the  allowable  limit  check  function,  provides  a  means  for 
the  user  to  manual ly  check  for  requirements  triggered  by  allowable 
limits  specifications.  As  with  the  requirements  check  function 
(Function  F2A),  this  function  is  used  when  the  current  OHMIS  data  base 
does  not  have  sufficient  information  in  it  about  the  factors  determining 
the  applicability  of  allowable  limits  for  the  OHMIS  allowable  limits 
evaluation  program  (Function  F3B)  to  'automatically'  determine  whether 
there  are  applicable  allowable  limits.  This  function  is  also  executed 
when  it  j_s  possible  to  identify  the  applicable  allowable  limits 
specifications,  but  these  specifications  are  such  that  they  cannot  be 
described  in  one  of  the  many  formats  for  describing  allowable  limits 
given  in  the  0S17  data.  Therefore,  these  allowable  limits  require  a 
manual  evaluation  by  the  user  to  determine  if  the  allowable  limit  has 
been  met.  As  with  the  requirements  check  function,  the  user  is  notified 
of  the  need  for  an  allowable  limits  check  by  the  Outstanding  Allowable 
Limits  Checks  Needed  List  (Output  010)  generated  each  day  as  a  part  of 
the  'log  on'  program  (Function  F1A). 

Function  F3D,  the  function  canceling  the  monitoring  of  outstanding 
(uncompleted)  OHMIS  forms,  allows  the  user  to  indicate  that  a  form  that 
has  been  generated  and  sent  out  for  completion  is  not  going  to  be 
returned.  This  removes  the  form  from  the  Outstanding  Data  Requests  List 
(Output  013;  DL26,  DL27,  and  DL28). 

FUNCTION  F4,  the  Scheduling  Function,  provides  for  the  scheduling 
(Function  F4A)  and  the  rescheduling  (Function  F4B)  of  tasks  that 
correspond  to  the  requirements  triggered  by  the  requirements  applica¬ 
bility  data.  Function  F4C  provides  for  the  automatic  generation  of  a 
set  of  monthly  schedule  data  (DS27)  from  the  regular  weekly  schedule 
availability  data  (DS26).  This  DS27  data  indicates  the  time  slots 
tentatively  available  for  scheduling  for  the  month.  The  OHMIS  program 
ensures  that  existing  DS27  data  always  includes  data  for  all  OHMIS  users 
for  at  least  two  months  in  advance  of  the  current  date. 
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FIGURE  6-7  (shown  on  the  following  six  pages)  provides  a  basic  flow 
diagram  of  the  core  OHMIS  data  processing  functions.  This  FIGURE 
shows  how  each  function  is  integrated  into  the  Menu  Selection 
Sequences.  As  indicated  above,  the  Menu  Selection  Sequences  that  are 
no  more  than  input  of  Data  Sets  or  generation  of  standard  outputs 
are  not  separately  described  as  functions  in  this  report.  The 
programs  for  these  functions  consist  only  of  input  and  output  of  the 
data  elements  described  in  detail  in  Section  6.6  (Data  Sets  (Outputs)) 
and  Section  6.7  (Inputs),  respectively.  These  Sections  follow  the 
detailed  description  of  the  Menu  Selection  Sequences  given  in  Section 
6.5.  Section  6.8  provides  the  Functional  Data  Flows  for  each  of  the 
11  core  OHMIS  data  processing  functions. 
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FIGURE  6-7  (Cont'd.) 


FIGURE  6-7  (Cont’d.) 


FIGURE  6-7  (Cont'd. 


6.5  MENU  SELECTION  SEQUENCES 


The  following  a;  <=  the  Menu  Selection  Sequences  used  to  allow  the  user 
to  input  or  request  outputs  from  the  core  OHMIS  programs. 


MENU  0  (First  Level  Menu) 


Please  select  the  basic  type  of  data  you  wish  to  use: 

1  =  QHMIS  requirements  data  (includes  requirements  suspense  and 

Reminder  Notice  Data) 

2  =  Forms  description  data 

3  =  Completed  forms  data  (DS14)  and  uncompleted  forms  data 

(DS22) 

4  =  Allowable  limits  data 

5  =  Type  code  (vocabulary  word/phrase)  data 

6  =  Time  period  specification  data  (DS20) 

7  =  Scheduling  data 


8  =  Address  data 


MENU  1  (Second  Level  Menu) 


Please  indicate  the  specific  type  of  requirements  data  you  wish  to 
use: 

1  =  OHMIS  requirement  (recommendation)  description  data  (DS1) 

2  =  Requirements  check  request  data  (0S2) 

3  =  (Information  triggered)  requirements  applicability  data 

( 0S3) 

4  =  Requirements  suspense  data  (i.e.,  date  triggered 

requirements  applicability  data),  including  entering  data  on 
"reminders",  i.e.,  date  triggered  Reminder  Notices  that  are 
not  requirements  (DS4) 

5  =  Requirements  implementation  data  (DS5),  includes  generating 

Notices  about  requirements  and  entering  requirements 
disposition  data 


MENU  1.1  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  QHMIS  requirement 
(recommendation)  description  data  (DS1): 

1  =  Add  a  requirement  description 

2  =  Examine  a  requirement  description 

3  =  Correct  a  requirement  description.  Requirement  descriptions 

cannot  be  changed  or  deleted.  If  the  requirement  has 
changed,  deactivate  the  old  requirement  (Selection  4)  and 
add  a  new  requirement  (Selection  1).  Menu  Selection  3 
should  only  be  used  if  the  requirement  description  was  never 
correct  at  any  time,  e.g.,  to  correct  a  typographical  error 
or  fill  in  missing  information.  For  this  reason  only 
descriptive  information  can  be  changed  and  blank  information 
filled  in  using  this  Menu  Selection.  If  nondescr iptive 
information  is  incorrect,  deactivate  the  incorrect 
requirement  description  data  and  generate  a  new  requirement 
description  with  the  correct  information.  [Note: 

Descriptive  information  is  data  elements  such  as 
instructions  or  explanations;  the  user  will  be  allowed  to 
change  only  limited  data  elements  and  these  will  not  include 
the  description  of  the  requirement,  in  order  to  ensure  that 
an  audit  trail  of  requirements  is  maintained  throughout  the 
history  of  OHMIS.] 

4  =  Deactivate  a  requirement.  This  Menu  Selection  should  only 

be  used  if  it  has  been  determined  that  an  existing 
requirement  should  not  be  used  any  longer.  If  the  use  of 
the  requirements  is  still  acceptable,  but  is  no  longer 
applicable,  then  Select  the  requirement  applicability  data 
Menu  Selections  (Menus  1.2,  1.3  and  4.1)  to  deactivate  the 
application  of  the  requirement. 


MENU  1.2  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  Requirements  Check  Request 
Data  (DS2) : 

1  =  Generate  a  Requirements  Check  Notice  (Output  01) 

2  =  Generate  an  Outstanding  Requirements  Checks  Needed  List 

(Output  02) 

3  =  Conduct  a  requirements  check  (See  Function  F2A) 


1 


MENU  1.3  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  information  triggered 
requirements  applicability  data  (DS3): 

1  =  Add  a  new  set  of  information  triggered  requirements 

applicability  data 

2  =  Examine  information  triggered  requirements  appl icabi 1 i ty 

data 

3  =  Correct  the  narrative  portions  of  a  set  of  information 

triggered  requirements  applicability  data.  Applicability 
data  cannot  be  changed  or  deleted.  If  the  application  has 
changed,  deactivate  the  old  applicability  data  and  add  new 
applicability  data.  Menu  Selection  3  should  only  be  used  if 
the  applicability  data  was  never  correct  at  any  time,  e.g., 
to  correct  a  typographical  error  or  fill  in  missing 
information. 

4  =  Deactivate  a  set  of  requirements  applicability  data.  Use 

this  Menu  Selection  to  provide  the  ‘end  date'  for  an 
application  of  a  requirement. 


MENU  1.4  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  requirements  suspense  data 
(DS4) : 

1  =  Add  a  new  set  of  requirements  suspense  data  (or  add  a  new 

Reminder  Notice) 

2  =  Examine  requirements  suspense  data 

3  =  Correct  the  narrative  portions  of  the  data  for  a  set  of 

requirements  suspense  data.  With  the  exception  of  Reminder 
Notice  type  of  requirements  suspense  data,  requirements 
suspense  data  cannot  be  deleted  or  changed.  If  the  data  has 
changed,  deactivate  the  old  data  and  add  new  data.  Menu 
Selection  3  is  only  to  be  used  to  correct  requirements 
suspense  data,  i.e.,  change  narrative  data  that  was  never 
corrected  any  time,  such  as  typographical  entries. 

4  =  Cancel  (deactivate)  a  set  of  requirements  suspense  data. 

This  Menu  Selection  is  used  to  stop  the  triggering  function 
of  a  set  of  requirements  suspense  data  before  the  'last 
suspense  date1  on  the  data  has  been  reached.  If  canceling 
Reminder  Notice  type  of  requirements  suspense  data,  the 
entry  of  a  deactivation  date  will  delete  the  requirements 
suspense  data  from  the  OHMIS  data  base.  This  Menu  Selection 
is  also  used  to  supply  an  end  date  for  a  set  of  requirements 
suspense  data  that  had  no  such  date  defined. 


MENU  1.5  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  requirements  implementation 
data  (DS5):  ' 

1  =  Generate  a  Requirement  Notification  and  Certification  Record 

(Output  03) 

2  =  Generate  an  Outstanding  Requirements  List  (Output  04) 

3  =  Enter  requirements  disposition  data  for  a  particular 

implementation  of  a  requirement,  i.e.,  enter  information 
about  who  executed  a  requirement,  when  a  requirement  was 
executed  and  in  what  way.  (See  Function  F2B.) 

4  =  Generate  a  Reminder  Notice  List  (Output  05) 

5  =  Change  requirements  disposition  data 


MENU  2  (Second  Level  Menu) 


Please  indicate  the  specific  type  of  forms  specification  data  you 
wish  to  use: 

1  =  Forms  description  data  (DS10),  includes  generation  of  forms 

2  =  Forms  subpart  data  (DS11) 

3  =  Forms  applicability  factors  data  (DS12) 

4  =  Forms  appl icab i 1 i ty  values  data  (DS13) 


MENU  2.1  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  forms  description  data 
(DS1Q) : 

1  =  Add  a  new  set  of  forms  description  data,  i.e.,  specify  the 

design  for  a  new  version  of  a  form 

2  =  Deactivate  forms  description  data 

3  =  Change  the  narrative  (i.e.,  nonforms  subpart  identifier) 

portions  of  the  forms  description  data,  e.g.,  titles  and 
instruction  data 

4  =  Examine  forms  description  data  (see  Function  F3A) 

5  =  Generate  a  form  for  use  in  data  entry.  Includes  generating 

a  previously  generated  blank  form  (i.e.,  one  with 
identification  information  on  it).  The  contents  of  which 
has  not  yet  been  completed.  (See  Function  F3A.) 


j 


MENU  2.2  (Third  Level  Menu) 

Please  indicate  how  you  wish  to  use  the  forms  subpart  data  (DS11): 

1  =  Add  new  forms  subpart  data 

2  =  Change  the  narrative  (nondata  element  type)  portion  of  the 

forms  subpart  data  (e.g.,  subtitles  and  instructions) 

3  =  Examine  forms  subpart  data 
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MENU  2.3  (Third  Level  Menu) 


* 


Please  indicate  how  you  wish  to  use  the  forms  appl icabi 1 ity  factors 
data  (0S12): 

1  =  Add  new  forms  applicability  factors  data 

2  =  Delete  forms  applicability  factors  data 

3  =  Change  forms  applicability  factors  data 

4  =  Examine  forms  applicability  factors  data 


MENU  2.4  {Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  forms  appl i cabi 1 i ty 
data  (DS13): 

1  =  Add  new  forms  applicability  values  data 

2  =  Delete  forms  applicabili ty  values  data 

3  =  Change  forms  applicability  values  data 

4  =  Examine  forms  applicability  values  data 


MENU  J  ( Second  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  completed  forms  data  (DS14) 
and  uncompleted  forms  data  (DS22): 

1  =  Enter  data  from  a  form  (see  Function  F3B) 

2  =  Delete  the  entire  completed  forms  data  (see  Step  6  of 

Function  F3B) 

3  =  Change  completed  forms  data  (see  Function  F3B,  exceot  no 

need  to  look  for  Data  Element  Sequence  Numbers  or  base  line 
information,  i.e..  Steps  4  through  7  of  Function  F3B.  If 
the  change  to  a  completed  data  element  type  is  to  complete 
the  value  for  the  data  element  type  from  the  completed  forms 
data,  see  Step  7  of  Function  F3B). 

4  =  Examine  a  completed  form 

5  =  Add  missing  data  element  information  on  a  previously 

completed  forms  data  set  (see  Step  7  of  Function  F3B) 

6  =  Cancel  an  outstanding  (uncompleted)  form,  i.e.,  indicate 

that  an  outstanding  form  is  not  going  to  be  submitted  (see 
Function  3D) 

7  =  Generate  an  Outstanding  Data  Requests  List  (Output  013) 
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MENU  4  (Second  Level  Menu) 

Please  indicate  the  specific  type  of  al 1 owable  1 i m i ts  data  you  wish 
to  use: 

1  =  Allowable  limits  specification  data  (DS17) 

2  =  Allowable  limits  applicability  factors  data  (DS15) 

3  =  Allowable  limits  appl icabi 1 i ty  values  data  (DS16) 

4  =  Allowable  limits  check  request  data  (DS18) 

5  =  Allowable  limits  check  table  data  (DS21) 
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MENU  4.1  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  allowable  limits 
specification  data  (DS17): 

1  =  Add  new  allowable  limits  specif ication  data 

2  =  Deactivate  existing  allowable  limits  specification  data 

3  =  Correct  the  narrative  portions  of  the  allowable  limits 

specification  data.  Note:  Allowable  limits  specification 
data  cannot  be  changed  or  deleted.  If  the  data  is  incorrect 
in  parts  other  than  the  narrative  portions  of  the  data  set, 
deactivate  the  incorrect  data  set  and  add  a  new  data  set 
with  the  correct  values. 

4  =  Examine  allowable  limits  specification  data 
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MENU  4.2  (Third  Level  Menu) 

Please  indicate  how  you  wish  to  use  the  allowable  limits 
applicability  factors  data  (DS15): 

1  =  Add  new  allowable  limits  applicability  factors  data 

2  =  Delete  allowable  limits  applicability  factors  data 

3  =  Change  allowable  limits  applicability  factors  data 

4  =  Examine  allowable  limits  appl icabi 1 i ty  factors  data 


MENU  4.3  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  allowable  limits 
applicability  values  data  (DSI6): 

1  =  Add  new  allowable  limits  applicability  values  data 

2  =  Deactivate  existing  allowable  limits  appl icabi 1 i ty  values 

data 

3  =  Correct  narrative  portions  of  the  allowable  limits 

applicability  values  data,  i.e.,  change  the  descriptive,  but 
not  the  values  portion  of  the  data.  Allowable  limits 
appl icabi 1 i ty  values  data  cannot  be  deleted  or  changed. 

4  =  Examine  allowable  limits  applicability  values  data 


MENU  4.4  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  allowable  limits  check 
request  data  ( 0S18) : 

1  =  Generate  an  Allowable  Limits  Check  Notice  (Output  09) 

2  =  Generate  an  Outstanding  Allowable  Limits  Checks  Needed  List 

(Output  10) 

3  =  Generate  an  Allowable  Limits  Evaluation  Summary  (Output  Oil) 

4  =  Conduct  an  allowable  limits  check  (see  Function  F3C) 


MENU  4.5  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  allowable  limits  table  data 
(US21) :  . . ' 

1  =  Add  a  set  of  allowable  limits  to  an  existing  allowable 

limits  table  (user  will  specify  the  allowable  limit  table 
identifier  ( ID25 ) ) 

2  =  Start  a  new  allowable  limits  table 

3  =  Deactivate  a  set  of  allowable  limits  table  data 

4  =  Deactivate  an  entire  allowable  limits  table 

5  =  Examine  an  allowable  limits  table  data  set 

6  = 


Examine  an  entire  allowable  limits  table 


MENU  5  (Second  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  type  code  (CT)  (vocabulary 
word/phrase)  data: 

1  =  Add  a  new  type  code 

2  =  Correct  the  narrative  description  portion  of  the  type  code 

data,  not  the  type  code  itself 

3  =  Examine  type  codes 

(In  the  entry  program  the  user  will  specify  the  type  of  type 
code,  e.g.,  requirement  type  code  (CT3)  that  the  user  wishes  to 
enter;  in  the  correction  program  the  user  will  specify  a 
particular  type  code;  in  the  examination  program  the  user  may 
specify  a  type  of  type  code  or  a  particular  type  code.) 

NOTE:  Menu  Selection  Sequences  5.1  and  5.2  will  have  very  limited 
access.  Most  OHMIS  users  will  not  be  able  to  add  or  correct  vocabu¬ 
lary  words.  The  vocabulary  words  include  the  generation  of  Data  Set  7 
data  (Data  Element  Type  Information). 


MENU  7  (Second  Level  Menu) 


Please  indicate  the  specific  type  of  scheduling  data  you  wish  to 
use: 

1  *  Task  type  data  ( DS23 ) 

2  =  Regular  weekly  schedule  of  availability  data  (DS26) 

3  =  Monthly  schedule  data  (DS27) 

4  =  Specific  task  scheduling  data  (DS24) 

5  =  List  of  qualified  employee  identifiers  by  task  type  and  by 

OHMIS  service  area  (0L34) 

6  =  Facility  data  by  task  type  (DS25) 


MENU  7.1  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  task  type  data  (DS23) : 

1  =  Add  new  task  type 

2  =  Correct  the  description  (narrative)  portions  of  the  task 

type  data.  This  would  include  correcting  only  those  data 
elements  in  the  DS23  data  set  that  are  not  affected  by  any 
other  data,  specifically  those  not  used  in  the  specific  task 
scheduling  data  (DS24).  Typographical  errors  in  the 
description  of  the  task  are  the  main  type  of  corrections. 

If  other  types  of  corrections  or  changes  are  desired,  the 
user  must  generate  new  task  type  data.  Task  type  data 
cannot  be  changed  or  deleted.  This  type  of  data  can  also 
not  be  deactivated.  Task  type  data  is  treated  as  though  it 
were  a  vocabulary  word  that  must  remain  in  the  system 
throughout  the  history  of  the  system. 

3  =  Examine  task  type  data 


MENU  7.2  (Third  Level  Menu) 

Please  indicate  how  you  wish  to  use  regular  weekly  schedule  data 
(0S26): 

1  =  Add  regular  weekly  schedule  data 

2  =  Provide  a  deactivation  (end)  date  for  regular  weekly 

schedule  data  (see  function  F4B).  The  DS26  data  will  be 
deleted  when  the  deactivation  date  is  reached. 

3  =  Change  the  regular  weekly  schedule  data  (see  Function  F4B) 

4  =  Examine  the  regular  weekly  schedule  data 


MENU  7.3  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  monthly  schedule  data 
(DS27) : 

1  =  Delete  the  monthly  schedule  data.  (See  Menu  Selection 

Sequence  7.2.2  (deactivate  regular  weekly  schedule  data); 
use  this  method  to  delete  monthly  schedule  data.) 

2  =  Change  the  monthly  schedule  data  (see  Function  F4B) ;  only 

the  availability  data  and  preferred  time  use  on  the  DS27 
data  can  be  changed;  to  change  a  schedule,  the  DS24  data 
(Menu  Selection  Sequence  7.4.1)  must  be  changed. 

3  =  Examine  the  monthly  schedule  data 

4  =  Generate  a  Daily  Schedule  (Output  014) 

5  =  Generate  a  Scheduling  Notice  (Output  015)  for  the  task. 

(Note:  Unlike  the  Scheduling  Notice  015  that  is  generated 
automatical ly  for  the  task  when  the  task  is  scheduled  in 
Function  F4A,  the  name  of  the  person  to  whom  the  Notice  is 
to  be  sent  is  specified  by  the  user,  rather  than 
automatical ly  determined  by  the  program.) 

6  =  Generate  a  List  of  Unscheduled  Tasks  (Output  017) 

7  =  Generate  a  "blank"  set  of  monthly  schedule  data,  i.e.,  DS27 

data  with  only  availability  and  preferred  time  use  (CT11)  on 
it,  no  tasks  scheduled  on  it.  (See  Function  F4C.) 


MENU  7.4  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  specific  task  scheduling  data 
(0524): 

1  =  Change  portions  of  a  specific  task  scheduling  data.  (Note: 

The  DS24  data  is  generated  by  the  OHMIS  program  (Function 
F4A)  whenever  requirement  implementation  data  (DS5)  is 
generated,  using  the  task  type  description  data  (DS23).  The 
user  may  change  only  selected  items  on  the  DS24  data.  See 
Menu  Selection  Sequence  7.4.4.  Some  of  these  changes  may 
result  in  rescheduling  (Function  F4B). 

2  =  Examine  the  specific  task  scheduling  data 

3  =  Generate  a  Scheduled  Task  Description  (Output  016) 

4  =  Specify  the  reschedule  for  a  task,  includes  specifying  that 

additional  person(s)  should  be  scheduled  to  perform  an 
already  scheduled  task  (see  Function  F4B) 


? 
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MENU  7.5  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  list  of  qualified  employee 
identifiers  by  task  type  and  by  OHMIS  service  area  (DL34): 

1  =  Add  a  new  employee  identifier  (ID4)  to  the  list 

2  =  Delete  an  employee  identifier  (ID4)  from  the  list 

3  =  Examine  the  list  for  an  OHMIS  service  area 


MENU  7.6  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  f aci 1 i ty  data 
(DS25) : 

1  =  Add  new  facility  data  by  task  type 

2  =  Delete  a  set  of  facility  data  by  task  tyoe 

3  =  Change  a  set  of  facility  data  by  task  type 

4  =  Examine  a  set  of  facility  data  by  task  type 


MENU  8  ( Second  Level  Menu) 


Please  indicate  the  specific  type  of  address  data  you  wish  to  use 

1  5  Current  user/position  identity  and  address  data  (DS9) 

2  =  Contact  and  location  data  (DS28) 


i 
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MENU  8.1  (Third  Level  Menu) 


Please  indicate  how  you  wish  to  use  the  current  user/p 
identity  and  address  data: 

1  =  Add  data 

2  =  Change  data 

3  =  Delete  data 

4  =  Examine  data 


MENU  8.2  (Third  Level  Menu) 


4 


Please  indicate  how  you  wish  to  use  the  contact  and  location  data 
(0S28) : 

1  =  Add  new  contact  and  location  data 

2  =  Change  the  task  scheduling  restrictions  information  ont  he 

contact  and  location  data  (see  Function  F4B) 

3  =  Change  other  parts  of  the  contact  and  location  data 

4  =  Delete  contact  and  location  data 


5  =  Examine  contact  and  location  data 


6.6  DATA  SETS  (INPUTS) 

The  following  are  the  descriptions  of  the  Data  Sets  that  are  used  in 
the  Functional  Data  Flows  describing  the  core  OHMIS  data  processing 
functions.  Data  Sets  can  be  considered  inputs  to  the  OHMIS  data 
base. 


6-38 


TITLES  OF  DATA  SETS 


Data  Set  Number 

Data  Set  Title 

DS1 

OHMIS  requirement  (recommendation) 
description  data  (see  ID6) 

DS2 

Requirements  check  request  data  (see  ID1) 

DS3 

(Information  triggered)  requirements  appli¬ 
cability  data  (see  ID5) 

OS  4 

Requirements  suspense  data  (i.e.,  date 
triggered  requirements  applicability  data), 
including  reminder  notice  data  (see  ID5) 

DS5 

Requirements  implementation  data  (see  ID9) 

DS6 

Triggering  step  requirement  implementation 
unit  identifier  types  data 

DS7 

Data  element  type  information 

DS8 

Values  data  for  requirement  applicability 
characteristics 

DS9 

Current  user/position  identity  and  address 
data 

DSIO 

Forms  description  data  (see  ID16) 

DS11 

Forms  subpart  data  (see  ID17) 

DS12 

Forms  applicability  factors  data 

DS13 

Forms  applicability  values  data  (see  ID19) 

DS14 

Completed  forms  data  (see  ID18)  [generic  de 
scription] 

DSlb 

Allowable  limits  applicability  factors  data 

DS16 

Allowable  limits  applicability  values  data 
(see  ID20) 

DS17 

Allowable  limits  specification  data  (see 

ID5 ) 

DS18 

Allowable  limits  check  request  data  (see 
ID22 ) 

Data  Set  Number 


Data  Set  Title 


DS19 

DS20 

DS21 

DS22 

DS23 

DS24 

DS25 

DS26 

DS27 

DS28 


Missing  data  element  information  (see  1021 
and  DL25 ) 

Time  period  specification  data  (see  ID24). 

Allowable  limits  table  data  (see  ID25) 

Outstanding  (uncompleted)  forms  monitoring 
data 

Task  description  data  (see  CT8) 

Specific  task  scheduling  data  (see  ID23) 

Facility  data  by  task  type  (CT8) 

Regular  weekly  schedule  availability  data 
(see  ID28) 

Monthly  schedule  data  (availability  and  use) 
Contact  and  location  data  (see  ID26) 


DATA  SET  1 


OHMIS  Requirement  (Recommendation)  Description  Data 


This  data  describes  the  characteristics  of  a  particular  requirement  (or 
recommendation).  DS1  data  is  entered  by  selected  users  (those  having 
the  correct  password)  using  Menu  Selection  Sequence  1.1.1.  This  data 
cannot  be  deleted  or  changed. 

The  DS1  data  is  referenced  in  the  requirements  applicability  data  (DS3), 
requirement  suspense  data  (DS4),  and  the  allowable  limits  specification 
data  (DS17),  all  of  which  prescribe  when  the  implementation  of  this 
requirement  is  to  be  triggered  (i.e.,  when  this  requirement  is 
applicable).  When  a  set  of  0S3  data  identifying  a  requirement  is  found 
to  be  applicable  (following  the  execution  of  a  triggering  step;  Function 
IB);  or  when  a  due  date  for  a  requirement  specified  in  a  set  of  DS4  data 
comes  due  (following  a  suspense  check;  part  of  Function  F1A);  or,  when  a 
data  entry  from  an  OHMIS  form  is  found  to  match  an  allowable  limit 
specified  in  DS17  data  and,  therefore,  triggers  a  requirement,  it  is  the 
information  on  the  requirement  given  in  the  DS1  data  that  is  used  to 
implement  the  requirement.  To  implement  a  requirement,  the  OHMIS 
program  generates  a  set  of  requirements  implementation  data  (DS5)  using 
the  DS3,  DS4,  or  DS17  data  that  triggered  the  requirement  and  the 
referenced  DS 1  data  to  supply  the  data  elements  for  the  generation  of 
the  0S5  data  set. 

For  some  types  of  requirements  that  are  triggered  by  information 
triggered  requirements  applicability  data  (DS3)  or  allowable  limits 
specifications  requirements  applicability  data  (DS17),  the  requirement 
will  "be  to  'implement  another  requirement  at  a  later  date  or  to 
implement  another  requirement  more  than  once  (periodically  triggered 
requirements).  For  example,  the  entry  of  data  that  is  found  to  match 
the  allowable  limits  specified  in  a  set  of  DSI7  data  may  not  only 
trigger  a  requirement  to  identify  a  corrective  action,  but  may  also 
trigger  a  requirement  to  follow  up  on  the  implementation  of  the 
corrective  action  within  30  days  (i.e.,  trigger  another  requirement 
at  a  1 ater  date) .  Another  example  would  be  a  requirement  triggered  by 
a  set  of  DS3  data  linked  to  the  entry  of  an  employee  identifier  (ID4) 
onto  the  new  hire  list  ( D L 4 )  (when  this  entry  had  previously  been 
identified  as  a  triggering  step).  This  DS3  data  might  require  setting 
up  suspense  data  (DS4)  to  periodically  trigger  a  routine  medical 
surveillance  examination  for  the  new  employee  that  was  entered  onto  the 
new  hire  list  (i.e.,  a  requirement  to  trigger  another  requirement  more 
than  once) . 


This  type  of  requirement  that  triggers  other  requirements  is  called  a 
'suspense  applicability  data  generating  requirement1.  When  the  DS3  data 
or  DS17  data  triggers  such  a  requirement,  i.e.,  when  it  is  found  that  a 
suspense  applicability  data  generating  requirement  is  applicable,  the 
OHMIS  program  does  not  generate  requirements  implementation  data  (DS5) 
as  usual,  but  instead  generates  a  new  set  of  requirements  suspense  data 
( D S 4 )  which  in  turn  will  trigger  the  specified  requirements 
implementation  data  (DS5)  when  (or  each  time)  the  due  date  on  the  newly 
created  DS4  data  comes  due. 
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Thus,  in  the  first  example  given  above,  when  the  DS17  data  found  that 
the  requirement  for  a  follow-up  in  30  days  was  applicable,  the  OHMIS 
program  would  not  generate  a  set  of  DS5  data,  but  would  generate  a  set 
of  0S4  data  specifying  that  another  requirement  (i.e.,  the  requirement 
for  the  follow-up  action)  is  to  be  triggered  in  30  days.  In  30  days, 
when  the  OHMIS  suspense  check  program  (Function  1A)  compares  the  current 
date  with  the  'first  suspense  date'  on  the  newly  created  0S4  data  and 
finds  that  the  requirement  has  come  due,  the  requirements  implementation 
data  (DS5)  for  the  follow-up  requirement  would  be  generated.  Similarly, 
in  the  second  example  given  above,  when  the  program  (Function  FIB)  found 
that  the  requirement  specified  in  the  0S3  data  (i.e., to  set  up  a  routine 
medical  surveillance  schedule  for  the  new  employee)  was  applicable,  the 
OHMIS  program  would  generate  a  set  of  periodically  triggered  DS4  data 
that  would  in  turn  generate  the  DS5  data  every  time  that  the  due  date 
for  routine  medical  surveillance  comes  due. 

DS1  data  for  suspense  appl i cabi 1 i ty  data  generating  requirements  is 
entered  by  the  user  in  the  same  way  as  other  requirements  description 
data  (DS1).  The  only  difference  is  that  the  DS1  data  entered  for  a 
suspense  applicability  data  generating  requirement  is  the  DS1  data  that 
will  be  referenced  in  the  0S4  data  that  is  generated  by  this  OS 1  and  is 
the  DSl  data  that  will  be  used  in  the  generation  of  the  DS5  data 
triggered  by  that  set  of  DS4  data.  For  example,  when  a  brief 
description  of  the  requirement  is  entered  for  the  DSl  data,  it  will  be 
the  description  of  the  requirement  that  this  DSl  data  is  triggering,  not 
the  requirement  itself.  In  the  above  example,  this  would  mean  that  the 
requirement  description  would  be  "take  follow-up  action  on  a  correction 
action  identified  30  days  previous”  (not  "schedule  follow-up  action  for 
30  days  from  now");  or  in  the  second  example  "conduct  medical 
surveillance"  (not  "schedule  medical  surveillance").  Similarly,  some  of 
the  fields  on  the  DS4  data  that  is  to  be  generated  by  this  requirement 
are  supplied  by  the  DS3  data  or  DS17  data  that  triggered  this 
requirement . 

Note:  The  OHMIS  program  only  checks  to  determine  if  a  set  of  DSl  data 
is  a  'suspense  applicability  data  generating  requirement',  when  the 
requirement  (DSl)  is  found  to  be  applicable  using  DS3  or  DS17 
requirements  applicability  data,  not  when  it  is  found  to  be  applicable 
using  DS4  (suspense  type)  requirements  applicability  data.  Therefore, 
when  the  DS4  data  generated  by  a  suspense  applicability  data  generating 
requirement  shows  that  the  requirement  has  come  due,  it  will  not  use 
the  DSl  data  to  generate  OS 4  data  again  (as  was  done  when  the  DS3  data 
or  DS17  data  that  found  the  requirement  to  be  applicable  was  what 
triggered  the  requirement ) ,  but  will  generate  the  requirements 
implementation  data  (DS5)  as  is  done  for  any  other  non-suspense 
applicability  data  generating  requirement.  Because  of  this,  it  is 
possible  to  use  the  data  from  a  'suspense  appl icabi 1 i ty  data  generating 
requirement'  type  of  DSl  data  as  both  the  data  to  generate  a  set  of  DS4 
data  (when  the  DSl  data  is  triggered  by  either  DS3  or  DS17  data)  and  the 
data  to  generate  the  DS5  data  (when,  at  a  later  date,  the  requirement 
specified  in  the  DSl  data  is  triggered  by  the  DS4  data  previously 
generated  by  the  DSl  data). 
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1.  OHMIS  requirement  identifier  (ID6).  Unique  value  assigned 
by  the  program  to  distinguish  this  set  of  DS1  data. 

2.  OHMIS  requirement  type  code  (CT3)  indicating  what  type  of 
requirement  is  being  described  in  this  DS1  data. 

3.  Is  this  a  'suspense  applicability  data  generating 
requirement ' ?  Answer:  Yes/No. 

4.  If  this  is  a  suspense  applicability  data  generating 
requirement,  the  brief  description  of  the  type  of  DS4  data 
that  will  be  generated  by  this  requirement,  e.g.,  "this 
requirement  will  generate  the  suspense  data  that  will  in  turn 
trigger  a  follow-up  on  corrective  actions  in  30  days".  This 
is  the  only  data  element  on  the  DS1  data  for  a  suspense 
applicability  data  generating  requirement  that  is  related  to 
the  actual  requirement  of  generating  suspense  appl icabi 1 i ty 
data.  The  rest  of  the  information  on  the  DS1  data  relates  to 
the  requirement  that  is  to  be  triggered  by  the  suspense 

appl icabi 1 i ty  data  (DS4)  that  is  generated  by  this  set  of 
'suspense  applicability  data  generating  requirement1  type  of 
DS1  data,  or,  is  used  to  generate  the  DS4  data. 

5.  If  this  is  a  suspense  applicability  data  generating 
requirement,  whether  the  DS4  data  generated  by  this 
requirement  will  be  implemented  more  than  once.  Answer:  Yes 
(the  DS4  data  generated  should  be  a  DS4  data  set  for  a 
periodically  triggered  requirement)  or  No  (the  DS4  data 
generated  should  be  for  a  one-time  triggered  requirement). 

6.  If  this  is  a  suspense  appl icabi 1 i ty  data  generating 
requirement,  the  amount  of  time  in  days  from  the  date  that 
the  requirement  was  found  to  be  applicable  and  the  DS4  data 
is  generated  _to  the  'first  suspense  date' .  This 
information  is  used  to  calculate  the  'first  suspense  date' 
that  will  be  entered  on  the  DS4  data  that  is  generated  from 
this  requirement. 

7.  If  this  is  a  suspense  applicability  data  generating 
requirement,  the  amount  of  time  in  days  that  is  to  constitute 
the  'prior  notification  time'  on  the  nS4  data  that  is  to  be 
generated . 

8.  Brief  description  of  this  requirement.  Used  on  the 
Outstanding  Requirements  List  (04). 

9.  Detailed  description  of  this  requirement.  Used  on  the 
Requirement  Notification  and  Cert i f icat i on  Record  (03). 

10.  Task  type  code  (CT8)  for  thp  type  of  action  specified  by 
this  requirement.  Used  in  scheduling  the  execution  of  this 
requirement . 
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This  field  may  be  blank  if  there  is  no  " schedu leable"  task 
associated  with  this  requirement.  A  "unscheduleable"  task  is 
one  for  which  the  hours  and  type  of  personnel  required  for 
the  task  are  either  too  small  to  schedule,  involve  time  of 
persons  other  than  the  OHMIS  users  or  persons  filling  OHMIS 
positions  and  therefore  cannot  be  scheduled,  or  are  too 
ill-defined  to  enable  the  generation  of  the  data  needed  to 
'automatically'  schedule  the  task,  i.e.,  generate  specific 
task  scheduling  data  (DS24).  Examples  of  requirements  that 
specify  unscheduleable  tasks  include  a  requirement  such  as 
"notify  the  facility  superintendent  of  condition  X"  or 
"obtain  past  medical  records  for  the  employee"  (tasks  that 
are  too  small  to  schedule);  or,  "evaluate  the  need  for 
additional  corrective  actions"  (a  task  too  ill-defined  to 
schedule).  Such  fasks  are  only  described  in  the  ‘detailed 
description  of  the  requirement'  field  on  the  DS1  data  and  are 
not  given  a  task  type  code  (CT8)  for  scheduling. 

Because  the  determination  of  who  is  to  execute  an  OHMIS 
requirement  (recommendation)  is  based  in  large  part  on  the 
type  of  task  (CT8)  involved  in  the  requirement,  if  no  CT8  is 
given  in  this  field,  there  are  special  checks  needed  for  the 
data  in  the  'person  who  should  execute'  field  given  on  the 
DS1,  DS3,  DS4,  DS17,  0S23,  and  DS 24  data  sets. 

11.  Description  of  the  Menu  Selection  Sequence  needed  for 
undertaking  the  uata  processing  actions  of  this  requirement. 
May  be  left  blank  if  none  are  specified. 

12.  Whether  or  not  this  is  a  mandatory  requirement  or  a 
recommendation.  Note:  Mandatory  requirements  need 
approval  for  any  disposition  of  the  implementation  of  this 
requirement  other  than  "fully  completed."  (See  "disposition 
approvals"  data  element  below.) 

13.  Organizational  level  type  code  (CT5)  for  the  type  of 
organi zational  level  at  which  this  requirement  is  to  be 
applied,  e.g.,  this  requirement  is  to  be  applied  by  (i.e. 
applied  for  one  or  more)  OHMIS  service  areas,  organizational 
units,  job  classes,  instal lations,  or  facilities. 

14.  The  range  of  identifiers  for  organizational  levels  (i.e., 
the  range  of  identifiers  for  OHMIS  service  areas, 
organizational  units,  job  classes,  installations,  or 
facilities)  for  which  this  requirement  is  supposed  to  be 
applied.  The  information  in  this  field  also  indicated 
whether  al 1  organizational  levels  of  types  specified  above, 
or  just  selected  ones,  must  apply  this  requirement.  If 
selected  ones  are  supposed  to  apply  this  requirement,  the 
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identifiers  for  this  selection  would  be  given.  Up  to  five 
ranges  of  identifiers  can  be  given  in  a  single  requirement. 
Additional  requirements  descrintion  data  (DSl)  would  be 
needed  if  there  are  more  than  five  ranges  of  identifiers,  but 
this  is  not  expected  to  be  frequently  the  case.  DA-wide 
requirements  would  answer  "all"  in  this  field  and  have  the 
OHMIS  service  area  as  the  type  .  organizational  level  at 
which  the  requirement  is  to  be  applied,  i.e.,  the 
organizational  level  type  code  given  above.  It  is  expected 
that  examination  of  each  OHMIS  service  area's  data  would  be 
made,  periodically,  to  determine  if  the  requirements 
applicability  data  for  the  requirement  (i.e.,  the  DS3,  0S4, 
or  0S17  data)  had  been  implemented  by  all  OHMIS  service 
areas . 

15 .  Description  of  the  general  applicability  of  this 
requirement  (beyond  that  given  in  the  organizational  level 
type  code  identified  above).  Statements  such  as  "whenever 
condition  X  exists"  may  be  included  here. 

16 .  The  OHMIS  user  type  code  (CT1)  or  the  OHMIS  position  type 
code  (CT2)  of  the  type  of  person  who  is  supposed  to  execute 
this  requirement,  i.e.,  the  primary  type  of  person  who  is 

to  be  notified  of  the  need  to  implement  this  requirement.  In 
this  field  the  user  may  specify  the  type  of  person  who 
should  execute  the  requirement.  This  field  may  be  left 
blank,  if  no  such  criteria  are  to  be  specified.  If  this 
field  is  completed  and  if  there  is  a  task  type  code  (CT8) 
given  above  for  this  requirement,  then  the  CT1  or  CT2 
provided  here  must  be  consistent  with  the  set  of  CTls  or  CT2s 
(if  any)  provided  in  the  task  type  description  data  (DS23) 
corresponding  to  the  above  CT8  for  the  type(s)  of  persons  who 
are  considered  "qual if iable"  (i.e.,  are  to  be  allowed  to 
perform  the  task)  for  the  task  involved  in  this  requirement. 

17.  Any  additional  description  of  the  above  type  of  user/position 
needed  to  enable  the  identif ication  of  the  specific 
applicable  person  from  the  generically  applicable  person 
specified  by  the  user/position  type  (CT1/CT2).  For  example 
an  OHMIS  position  type  will  be  the  OHMIS  Liaison  Supervisor 
(i.e.,  the  supervisor  for  an  organizational  unit  who  is 
responsible  for  interaction  with  OHMIS;  this  may  be  the  same 
as  the  "regular"  supervisor).  The  additional  description  may 
say  "the  OHMIS  Liaison  Supervisor  for  the  job  class  in  which 
the  hazard  was  found,"  thus  enabling  the  specific  type  of 
OHMIS  Liaison  Supervisor  to  be  identified  in  a  generic  way. 

13.  The  OHMIS  user  type  code  (CT1)  or  OHMIS  position  type  code 
(CT2)  of  the  management  person  (if  any)  who  should  be 
notified  of  the  requirement  in  order  to  supervise  its 
execution.  Left  blank  if  there  is  io  be  no  such  management 
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person  or  if  the  user  does  not  wish  to  specify  the  type  of 
person  who  should  be  this  management  person  for  this 
requirement . 

19.  Any  additional  description  of  the  above  type  of 
user/position . 

20 .  Types  of  disposition  of  this  requirement,  which  require 
approval .  Answers  are  Yes/No  for  each  of  the  four 
dispositions  of  a  requirement:  (1)  fully  completed;  (2) 
partially  completed;  (3)  aborted  (i.e.,  decided  not  to 
implement);  and,  (4)  found  not  to  be  applicable.  An  answer 
of  "Yes"  for  the  first  type  of  disposition  would  mean  that 
the  determi nat ion  that  this  requirement  has  been  fully 
completed  requires  approval,  i.e.,  this  requirement  requires 
review  by  someone  other  than  the  executor  of  the  requirement 
to  confirm  that  the  requirement  has  been  fully  executed;  for 
the  second  type  of  disposition,  a  "Yes"  would  mean  that  the 
requirement  cannot  be  considered  executed  if  only  partially 
completed  unless  there  is  approval  for  this  disposition;  for 
the  third  type  of  disposition,  a  "Yes"  would  mean  that  the 
requirement  cannot  be  aborted  without  approval;  and,  for  the 
fourth  type  of  disposition,  a  "Yes"  would  mean  that  the 
requirement  can  not  be  determined  to  be  not  applicable 
without  approval.  The  answer  must  be  "Yes"  for  the  last  3 
types  of  disposition,  if  this  is  a  mandatory  requirement. 

21 .  The  QHMIS  user  type  code  (CTI)  or  QHMIS  position  type  code 
(CT2)  for  the  person,  if  any,  who  must  approve  the 
disposition  of  the  requirement.  May  be  left  blank  if  there 
is  to  be  no  such  approvals  of  if  the  user  does  not  wish  to 
specify  the  type  of  person  who  is  to  approve  the 
requirement . 

22.  Recommended  (or  required)  length  of  time  for  completing 
this  requirement.  May  be  left  blank  if  no  length  of  time  is 
specified. 

23.  For  periodic  suspense  requirements,  e.g.  routine 
surveillance,  the  required  interval  between  each 
implementation  of  the  requirement,  e.g.,  this  requirement  is 
to  be  implemented  every  sixty  days.  For  mandatory 
requirements  the  program  will  check  that  this  interval  is 
used  in  any  requirements  suspense  data  (DS4)  for  this 
requirement.  For  recommended  requirements  the  user  must 
indicate  (document)  in  the  DS4  data  whether  the  DS1  specified 
interval  is  being  used,  and  if  not,  why  not.  The  program 
will  check  for  consistency  between  the  DS4  and  DSl  data  for 
this  data  element. 

The  required  in*e**val  data  supplied  here  is  also  used  to 
provide  this  value  on  the  DS4  data  generated  by  this  OS  1 
data,  if  this  DSl  data  is  a  'suspense  applicabil i ty  data 
generating  requirement'. 
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24.  For  periodic  suspense  requirements,  the  length  of  time  that 
the  requirement  must  be  executed,  e.g.,  the  survey  is  to  be 
conducted  periodically  (at  the  interval  specified  above)  for 
a  period  of  three  years,  for  six  months  or  indefinitely  etc. 
For  mandatory  requirements  the  program  will  check  that  this 
length  of  time  is  used  in  specifying  the  "last  suspense  date" 
given  in  any  requirement  suspense  data  (DS4)  for  this 
requirement.  For  recommended  requirements  the  user  must 
indicate  (document)  in  the  DS4  data  whether  the  DSl  data 
specified  length  of  time  is  used  and  explain  why  rot.  The 
program  will  check  for  consistency  between  the  DS 4  and  DSl 
data.  The  length  of  time  that  the  requirement  must  be 
executed  is  given  in  terms  of  days  from  the  current  date 
(i.e.,  days  from  the  date  that  this  requirement  was 
triggered).  This  value  may  be  left  blank,  if  the  requirement 
is  one  that  is  to  be  executed  for  an  indefinite  period  of 
time. 

This  time  period  is  also  used  to  calculate  the  'last  suspense 
date'  and  enter  it  onto  the  DS4  data  generated  by  this  DSl 
data  for  'suspense  applicability  data  generating 
requirements" . 

25.  Length  of  time  (if  any)  that  the  hard  copy,  (i.e.,  the  one 
with  the  signatures)  of  the  Requirement  Notification  and 
Certification  Record  (03)  generated  as  a  result  of  an 
implementation  of  this  requirement,  must  be  maintained. 

The  03  output  is  not  only  a  notification  to  the  user  of  the 
requirement,  but  can  also  become  the  hard  copy  on  which  the 
signatures  of  the  persons  who  executed  and  approved  the 
execution  oc  the  requirement  are  stored.  This  would  be  the 
case  for  those  requirements  of  sufficient  significance  that  a 
record  of  these  signatures  should  be  maintained.  Answer  can 
be  'O'  days. 

26.  Requirement  identifier  (  1D6)  for  the  requirement. 
superseded  by  this  requirement,  if  any. 

27.  Requirement  identifier  ( IP6)  for  the  higher  level 
requirement  for  which  this  requirement  constitutes  an 
equivalent  (as  when  a  local  level  specifies  a  requirement 
that  is  not  the  same  as,  but  is  equivalent  to,  a  higher  level 
requirement),  if  any. 

28.  Document  type  code  (CT6)  for  tr.e  type  of  document  that  is 

the  source  for  this  requirement,  if  any.  An  example  would  be 
the  document  type  code  assigned  to  the  federal  OSHA 
standards . 

39.  Document  identifier  (  I D  3 )  for  the  specific  document  that  ' 

the  source  of  this  requirement,  if  any.  An  example  would  h" 
the  OHM  IS  document  identifier  as  sianed  to  the  OSHA  1°10 
standards  promulaat.ed  on  i  given  date. 
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30.  Document  subpart  identifier  (ID15)  identifying  the  specific 
part  of  the  above  referenced  document  which  contains  the 
specific  regulation,  prescription  or  standard  that  is  the 
source  of  this  requirement. 

31.  Any  additional  information  needed  to  describe  the  specific 
part  of  the  above  referenced  document  which  contains  the 
regulation,  prescription  or  standard  that  is  the  source  of 
this  requirement. 

32.  Document  identifiers  (ID3),  if  any,  containing  a 
description  of  the  rationale  for  this  requirement  (other  than 
regulations),  including  the  identification  of  any  mishaps 
that  led  to  the  development  of  this  requirement.  The 
documents  identified  can  include  studies  conducted  or  other 
reasons  why  this  requirement  was  developed.  The  information 
in  this  field  provides  a  mechanism  for  retaining  the  "lessons 
learned"  which  resulted  in  this  requirement.  This 
information  is  often  lost  (because  there  is  no  such  mechanism 
for  storing  it)  and  can  then  result  in  a  misinterpretation  of 
the  requirement  or  a  failure  to  recognize  the  requirement's 
significance.  It  is  considered  important,  therefore,  to 
retain  or  reference  this  information. 

33.  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
~(Td14)  of  the  DA  office  promulgating  this  requirement  or 
recommendation. 

34.  Employee  identifier  (ID4)  of  the  individual  person,  if  any, 
promulgating  this  requirement  or  recommendation. 

35.  Start  date  for  when  this  requirement  is  effective,  i.e., 
beginning  date  when  requirement  applicability  data  (i.e., 

DS3,  DS4,  or  DS17  data)  for  this  requirement  can  be 
generated . 

36.  End  date  for  when  this  requirement  is  no  longer  to  be  used, 
i.e.  when  the  applicability  of  this  requirement  is  no  longer 
to  be  specified  in  requirements  applicability  data  (DS3,  DS4, 
or  DSI7  data).  Note:  Historical  data  on  all  requirements  is 
to  be  maintained.  Requirements  description  data  (DS1)  cannot 
be  deleted  or  changed  (except  to  make  corrections) .  This 
provides  an  audit  trail  for  the  DA  requirement  history. 
However,  a  requirement  may  become  outdated  in  which  case  this 
end  date  for  the  applicability  of  the  requirement  is  entered. 
The  end  date  may  be  left  blank  if  the  requirement  is  still  in 
effect. 

37.  The  OHMIS  user  identifier  (ID13)  of  the  person  approving 
deactivation  of  this  requirement. 

38.  The  employee  identifier  (ID4)  of  the  above  person. 
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Requirements  Check  Request  Data 


This  data  describes  a  particular  request  for  a  check  for  information 
triggered  requirements,  i.e.,  a  request  to  execute  a  requirements  check 
(Menu  Selection  Sequence  1.2.3;  Function  F2A).  This  data  is  not 
entered.  It  is  generated  by  the  computer  program  each  time  the  user 
executes  a  step  that  has  been  identified  as  a  triggering  step  and  the 
OHMIS  data  base  at  the  time  of  the  triggering  step  was  executed  was 
found  to  not  be  sufficient  to  obtain  all  values  for  requirements 
applicability  characteristics  (DS8);  that  is  if  it  was  not  possible  to 
determine  the  applicability  of  requirements  from  existing  OHMIS  data, 
the  requirements  check  request  data  (DS2)  is  generated.  If  it  is 
possible  to  determine  which  requirements  are  applicable  using  the 
existing  OHMIS  data  base,  i.e.,  no  requirements  check  is  needed,  the 
program  generates  the  requirements  implementation  data  (DS5)  directly 
following  the  triggering  step,  the  DS2  data  generated  by  the  triggering 
step  is  deleted,  and  the  user  does  not  need  to  execute  a  requirements 
check.  DS2  data  is  used  to  generate  the  Requirements  Check  Notice  (01) 
telling  the  user  that  a  requirements  check  is  needed. 

1.  Requirements  check  request  identifier  (ID1).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS1  data. 
Use  to  execute  the  requirements  check  program  (Menu  Selection 
Sequence  1.2.3;  Function  F2A)  and  to  link  information 
triggered  requirements  applicability  data  (DS3)  to  this 
requirements  check  request. 

2.  OHMIS  service  area  identifier  (ID10)  for  the  service  area 
of  the  user  that  triggered  this  requirement  check  request. 
This  is  obtained  from  the  "log  on"  information  of  the  user. 
Used  by  the  program  to  quickly  identify  those  requirements 
check  request  data  sets  (DS2)  applicable  to  a  given  OHMIS 
service  area. 

3.  Triggering  step  identifier  (ID2)  for  the  triggering  step  at 
which  this  requirements  check  request  data  was  triggered. 

4.  Date  on  which  this  requirements  check  request  was 
triggered,  i.e.,  the  date  on  which  this  DS2  data  was 
generated. 

5.  Identifier  or  values  for  the  identifier  types  (or  data 
element  types)  that  are  the  requirement  implementation  unit 
types  1  through  5  for  the  above  referenced  triggering  step. 
(See  triggering  step  requirements  implementation  identifier 
type  data  (DS6)  for  an  explanation  of  triggering  steps  and 
requirement  implementation  units.) 

The  DS6  data  identifies  the  codes  for  identifier  types 
(CT10)  or  data  element  types  (CT4)  that  are  the  requirement 


implementation  units,  while  this  DS2  data  field  provides  the 
identifiers  or  values  for  the  identifier  types  or  data 
element  types.  For  example,  if  one  of  the  0S6  identifier 
types  is  information  on  the  identity  of  an  employee  (i.e., 
the  identifier  type  is  "employee"),  the  DS2  value 
(identifier)  would  be  the  actual  employee  identifier  (ID4) 
for  a  specific  employee.  The  identifier  or  values  data  is 
entered  as  a  part  of  the  execution  of  the  triggering  step 
which  triggered  this  requirements  check  request.  There  may 
be  up  to  five  types  of  requirement  implementation  units  (DS6) 
for  a  given  triggering  step  and  therefore  there  may  be  up  to 
five  values  for  these  units  (DS2  data)  in  a  given 
requirements  check  request  data  set. 


DATA  SET  3 


(Information  Triggered)  Requirements  Applicability  Data 


This  data  prescribes  the  types  of  data  elements  that  determine  whether  a 
requirement  is  applicable  and  what  the  values  of  these  specified  data 
elements  (called  applicability  variables)  must  be  for  a  requirement  to 
be  considered  to  be  applicable,  i.e.,  it  describes  the  information 
triggers  for  information  triggered  requirements.  Applicability 
variables  can  consist  of  values  for  the  up  to  5  requirement  implementa¬ 
tion  units  that  can  be  entered  at  the  time  that  a  triggering  step  for  a 
requirement  is  executed  and  the  up  to  5  characteristics  for  each  of 
these  units.  DS3  data  is  entered  by  the  user  using  Menu  Selection 
Sequence  1.3.1.  Historical  data  is  maintained.  DS3  data  cannot  be 
changed  or  deleted.  If  a  set  of  DS3  data  has  been  changed  it  should  be 
deactivated  and  new  DS3  data  generated. 

1.  Requirement  application  identifier  (ID5).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS3  data. 

2.  OHMIS  service  area  identifier  (ID10)  for  the  service  area 
covered  by  (and,  in  most  cases,  propagating)  this  application 
of  the  requirement.  The  program  will  only  look  for 
applications  of  requirements  for  the  OHMIS  service  area  of  the 
user  operating  the  OHMIS  system  at  the  time  that  the 
triggering  step  or  requirements  check  is  occurring.  The  OHMIS 
service  area  identifier  (ID10)  of  a  user  is  determined  at  the 
time  that  the  user  logs  on  to  the  OHMIS  system. 

3.  OHMIS  requirement  identifier  (ID6)  for  the  requirement  for 
which  this  data  set  is  prescribing  the  applicability 
qualifications . 

4.  Triggering  step  identifier  (ID2)  for  the  triggering  step  at 
which  a  check  for  this  applicability  data  is  to  be  made. 

5.  The  identifier  for  the  organizational  level  type  at  which 
the  determination  of  whether  this  requirement  applies  is  to  be 
made.  This  can  be  a  OHMIS  service  area  identifier  (ID10),  an 
installation  identifier  (IDll),  an  organizational  unit 
identifier  (ID12),  a  job  class  identifier  ( 107 ) ,  or  a  facility 
identifier  (108)  depending  on  the  purview  of  the  requirements 
applicability.  The  requirement  description  data  (DS1)  for  the 
above  referenced  requirement  identifier  (106)  prescribes  at 
what  type  of  organizational  level  (i.e.,  CT5)  the  require¬ 
ment  is  to  be  applied  (e.g.,  by  service  area,  instal lation, 
etc.);  this  DS3  field  provides  an  actual  value  for  the 
organizational  level  at  which  it  applies.  The  entry  program 
must,  therefore,  check  that  the  identifier  value  supplied  here 
is  consistent  with  the  type  of  identifier  for  an  organiza¬ 
tional  level  (CT5)  provided  in  the  DS1  data  for  the 
requirement. 
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6.  The  range  of  applicability  values  or  identifiers,  if  any, 
for  a  requirement  implementation  unit  type  1.  This  is  the 
range  of  values  (if  any  are  specified)  that  the  data  element 
type  that  is  the  requirement  implementation  unit  type  one  for 
the  above  reference  triggering  step  must  have  for  this  require¬ 
ment  to  be  considered  applicable.  (The  identifier  type  (CT10) 
or  data  element  type  (CT4)  for  the  requirement  implementation 
units  for  a  triggering  step  are  given  in  the  DS6  data.).  This 
range  of  values  or  identifiers  may  be  blank,  if  there  are  no 
prescriptions  of  what  this  data  element  type  must  be  for  the 
requirement  to  be  considered  applicable.  For  example,  the 
triggering  step  that  is  associated  with  the  entry  of  a  job 
class  identifier  (ID7)  onto  the  vacant  job  class  list  (DL1), 
the  job  class  identifier,  is  the  requirement  implementation 
unit.  It  may  be  that  a  requirement  associated  with  this 
triggering  step  is  applicable  regardless  of  what  job  class 
identifier  is  entered,  i.e.,  just  the  entry  of  any  job  class 
is  to  trigger  a  requirement.  In  this  case  the  applicability 
value  for  the  requirement  implementation  unit  would  be  left 
blank.  However,  there  may  be  some  requirements  that  are 
triggered  by  this  triggering  step  that  apply  only  if  one  or 
more  specific  job  class  identifiers  are  entered;  in  this  case 
one  of  the  ranges  of  specific  job  class  identifiers  that  must 
have  been  entered  in  the  above  referenced  triggering  step  for 
the  requirement  to  be  considered  applicable  would  be  entered 
as  the  range  of  applicability  values  for  the  requirement 
implementation  unit  in  this  field.  If  there  is  more  than  one 
range  of  applicability  values  then  more  than  one  set  of 
requirements  applicability  data  (DS3)  must  be  entered. 

A  range  of  values  is  entered  in  one  of  the  following  10 
ways:  For  the  requirement  to  be  considered  applicable  the 
value  must  be:  a)  equal  to;  or,  b)  not  equal  to  one  of  the 
following:  1)  a  value;  2)  greater  than  a  given  value;  3)  less 
than  a  given  value;  4)  greater  than  a  certain  low  end  value 
and  less  than  a  certain  high  end  value,  i.e.,  within  a 
specified  range;  or  5)  less  than  a  certain  low  end  value  or 
greater  than  a  certain  high  end  value,  i.e.,  outside  a 
specified  range.  Note:  These  10  methods  for  entering  ranges 
of  values  are  used  for  all  ranges  of  values  entered  in 
QHMIS.  Although  the  five  "not  equal  to"  types  of  methods  for 
entering  ranges  of  values  will  not  be  used  very  frequently, 
they  may  be  used  in  the  ranges  of  values  given  in  the 
allowable  limits  (and  unallowable  limits)  specification  data 
(DS17) . 

Because  in  this  range  of  values  the  user  is  specifying  the 
applicability  values  for  a  particular  requirement 
implementation  unit  (i.e.,  one  of  five  data  element  types 
specified  on  the  triggering  step  requirement  implementation 
unit  data  element  types  data  (DS6)),  the  entry  program  must 


DATA  SET  3 


check  to  see  that  the  range  of  values  entered  are  consistent 
with  the  types  of  data  elements  for  the  requirement 
implementation  unit  to  which  this  applicability  values  data 
refers. 

7.  The  data  element  type  code  (CT4),  if  any  is  specified,  for 
the  applicability  characteristic  type  1  (for  requirement 
implementation  unit  type  1)  for  this  application  of  the 
requirement.  As  indicated  above,  applicability  variables  are 
those  data  element  types  which  are  used  to  determine  whether 
an  information  triggered  requirement  is  applicable  and  the 
requirement  implementation  unit  may  be  an  applicability 
variable,  i.e.,  its  value  may  determine  whether  the  require¬ 
ment  is  applicable.  However,  there  may  also  be  character¬ 
istics  which  the  requirement  implementation  unit  must  have  for 
the  requirement  to  be  considered  applicable.  These  are 
referred  to  as  applicability  characteristics.  The  data  ele¬ 
ment  type  that  describes  the  first  type  of  characteristic  that 
the  first  requirement  implementation  unit  (i.e.  type  1)  must 
have  for  the  requirement  to  be  applicable  is  the  one  given  is 
this  field.  For  example,  if  a  requirement  is  to  be  triggered 
by  the  entry  of  an  employee  identifier  (ID4)  onto  the 
potential  new  hire  list  (DL2),  this  requirement  may  apply 
regardless  of  the  characteristics  of  the  employee  (in  which 
case  there  would  be  no  applicability  characteristics  type  of 
applicability  variables  for  this  requirement  implementation 
unit)  or  it  may  be  applicable  only  if  the  employee  is  over  age 
50  (in  which  case  the  "employee  age"  would  be  the 
applicability  variable  for  the  requirement  implementation 
unit). 

Bee? in  this  data  element  the  user  is  describing  the  type 
of  cnaracteristics  that  requirement  implementation  unit  type  1 
must  have,  the  program  must  check  that  the  data  element  type 
information  (DS7)  for  the  data  element  type  code  (CT4)  entered 
here  is  a  type  of  data  element  that  describes  characteristics 
of  the  type  of  requirement  implementation  unit  that  is  require 
ment  implementation  unit  type  1.  (Requirement  implementation 
unit  type  1  is  defined  in  the  DS6  data  for  the  above  reference 
triggering  step.)  For  example,  "employee  age"  could  only  be 
given  as  the  data  element  type  for  the  type  of  appl icabil ity 
characteristic  if  requirement  implementation  unit  type  one  was 
an  employee  identifier  (ID4);  it  would  not  be  consistent  if 
this  applicability  characteristic  was  given  and  the  require¬ 
ment  implementation  unit  being  described  was  anything  other 
than  an  employee  identifier. 

8.  The  range  of  applicability  values  for  applicability 
characteristics  type  1  (for  requirement  implementation  unit 
type  1).  This  data  prescribes  the  range  of  values  data  for 
the  first  applicability  characteristic  for  the  first 
requirement  implementation  unit,  i.e.  the  values  that  the 
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above  referenced  applicability  characteristic  for  this 
requirement  implementation  unit  must  have  for  the  requirement 
to  be  considered  applicable.  In  the  above  example,  in  which 
the  data  element  type  for  the  applicability  characteristic  was 
"employee  age,"  this  field  would  have  the  range  of  ages  for 
which  the  requirement  is  applicable  (i.e.,  in  the  above 
example,  the  range  would  be  "greater  than  50"). 

9.  The  data  element  type  codes  (CT4)  and  range  of  applicability 
values  for  applicability  characteristic  types  2  through  5  for 
requirement  implementation  unit  type  1  (if  any  are  specified). 


10.  The  range  of  applicability  values  for  requirement 
implementation  units  two  through  five  and  the  corresponding 
sets  of  up  to  five  applicability  characteristics  (data  element 
types  and  values)  for  each  of  these  requirement  implementation 
units  (if  any  are  specified). 

11.  Supplement  to  the  requirement  description.  This  is  any 
additional  explanation  of  the  requirement  triggered  by  this 
set  of  DS3  data  beyond  the  description  given  in  the 
requirement  description  data  (DS1)  that  explains  this 
particular  application  of  the  requirement. 

12.  Description  of  the  conditions  that  will  have  existed  that 
will  trigger  the  implementation  of  this  requirement.  This 
description  is  used  in  output  such  as  the  Requirement 
Notification  and  Certification  Record  (03)  to  inform  the  user 
of  why  this  requirement  was  implemented.  It  includes  a 
description  of  those  applicability  variables,  the  values  for 
which  are  to  be  included  in  the  description  of  why  this 
requirement  was  triggered  that  will  be  given  on  the  output. 

For  example,  a  description  of  the  rational  for  implementing  a 
requirement  that  was  triggered  by  the  entry  of  a  job  class 
identifier  (ID7)  onto  the  vacant  job  class  list  (DLl)  (i.e., 
DS1)  would  probably  include  the  title  of  the  job  class.  This 
would  be  done  by  statements  such  as  "This  requirement  was 
triggered  by  the  entry  of  the  below  referenced  job  class 
title  on  the  Vacant  Job  Class  List."  This  statement  would 
appear  on  an  03  type  of  output  followed  by  the  values  for  the 
applicability  variables  identified  in  this  data  set. 

13.  Description  of  any  additional  checks  that  the  user  should 
exercise  to  determine  whether  the  requirement  is  applicable 
and  should  be  implemented,  beyond  those  specified  in  the 
applicability  variables  data.  This  would  include  restrictions 
on  the  applicability  of  the  requirement  that  cannot  be  speci¬ 
fied  through  applicability  variables  data.  For  example,  if 
something  or  someone  that  is  not  a  requirement  implementation 
unit  (and  therefore  cannot  be  covered  in  the  applicability 
variables  data)  must  have  a  certain  characteristic  for  the 
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requirement  to  be  considered  applicable,  this  applicability 
information  would  be  described  here.  Also,  if  the  user  wishes 
to  indicate  that  the  requirement  need  not  be  implemented  if 
the  same  requirement  has  already  been  done  recently  (within  a 
specified  time  period),  this  information  would  be  described 
here.  It  will  be  suggested  that  the  description  given  here 
include  the  Menu  Selection  Sequence  for  conducting  the  type  of 
data  analysis,  if  any,  needed  to  conduct  this  additional 
check. 

14.  The  start  date  (activation  date)  for  this  application  of  the 
requirement.  This  is  the  date  that  this  application  of  the 
requirement  is  to  be  activated.  This  date  is  used  to  enable 
an  audit  trail,  i.e.  a  trail  to  identify  all  applications  of  a 
requirement  that  were  active  as  of  a  given  date. 

15.  The  end  date  (deactivation  date)  for  this  application  of  the 
requirement.  Historical  requirements  aoplicability  data  (DS3 
data)  is  maintained  by  OHMIS,  i.e.,  even  when  an  application 
of  a  requirement  is  no  longer  active,  data  about  that 
application  is  kept  in  order  to  provide  an  audit  trail. 
Therefore,  to  stop  the  application  of  a  requirement  a 
deactivation  date  must  be  entered. 

16.  Employee  identifier  (104)  and  OHMIS  user  identifier  (ID13)  'or 
the  person  who  prescribed  this  application  of  the 
requirement. 

17.  Employee  identifier  (104)  and  OHMIS  user  identifier  (1013)  for 
the  person  who  approved  deactivation  of  this  requirement. 

18.  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
( 1014)  for  the  user/position  of  the  person  who  is  supposed 

to  execute  this  requirement,  i.e.,  the  primary  person  who 
is  to  be  notified  of  this  requirement.  This  is  the  office 
(user  or  position)  that  is  designated  to  execute  this 
requirement  for  the  OHMIS  service  area  (1010)  in  which  this 
set  of  requirements  applicability  data  (DS3)  was  generated. 
This  field  is  only  completed  if  the  requirement  description 
data  (0S1)  referenced  by  the  above  requirement  identifier 
(106)  does  not  specify  a  task  type  code  (CT8)  for  the 
requirement.  This  is  because,  if  there  is  no  task  associated 
with  the  requirement,  it  will  not  be  possible  to 
'automatically1  determine  who  is  suppose  to  execute  the 
requirement  and,  therefore,  the  user  must  supply  the  identity 
of  this  person  in  this  field.  If  the  DS1  data  for  the  above 
106  on  this  set  of  0S3  data  specifies  the  type  of  OHMIS 
user/position  (CT1  or  CT2)  that  should  execute  this  task,  the 
1013  or  1014  given  here  must  be  consistent  with  these  CT1  or 
CT2  codes;  the  determination  of  this  consistency  is  based  on 
the  OHMIS  user/position  identifier  by  OHMIS  service  area  list 
(DL8).  (Note:  the  advantage  of  giving  an  OHMIS  user  or 
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position  identifier  in  this  field  instead  of  an  employee 
identifier  is  that  the  actual  individual  filling  the  user  or 
position  office  can  be  changed  without  having  to  change  the 
applicability  data;  the  actual  person  filling  the  user  or 
position  office  is  determined  at  the  time  that  the 
requirements  implementation  data  (DS5)  is  generated. 

19.  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
(ID14)  (or,  if  not  a  user/position,  the  employee  identifier 

( ID4) )  for  the  management  person,  if  any,  who  should  be 
notified  of  the  requirement  in  order  to  supervise  its 
execution.  Must  be  consistent  with  the  DS1  data,  if  any  was 
provided. 

20.  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
(ID14)  (or,  if  not  a  user/position,  the  employee  identifier 
(ID4)),  if  any  of  the  person  who  is  supposed  to  approve  the 
disposition  of  the  requirement.  This  identifier  must  be 
consistent  with  the  type  of  user/position  specified  in  the  0S1 
data,  if  any  was  specified.  If  the  DS1  data  indicated  that  no 
such  approvals  are  necessary,  this  data  element  would  be  left 
blank. 
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Requirements  Suspense  Data 
(Date  Triggered  Requirements  Applicability  Data) 

This  data  prescribes  the  occasion  (date  or  dates)  on  which  a  requirement 
is  to  be  implemented,  i.e.,  the  triggers  for  date  triggered 
requirements.  It  is  similar  in  effect  to  the  information  triggered 
requirements  applicability  data  (DS3)  which  is  for  requirements 
triggered  by  the  entry  of  certain  information  rather  than  by  a 
particular  "due  date."  To  trigger  a  date  triggered  requirement  from  the 
DS4  data,  the  QHMIS  program  conducts  a  suspense  check  (see  Step  F1A-2  in 
Function  F1A)  consisting  of  a  review  of  all  requirements  suspense  data 
(DS4).  A  suspense  check  is  done  periodically  (once  each  day  that  the 
OHMIS  system  is  used)  and  includes  the  identification  of  those 
requirements  that  have  come  due  and  the  generation  of  requirements 
implementation  data  (DS5)  for  these  requirements. 

DS4  data  is  generated  in  two  ways:  (1)  It  may  be  entered  by  the  user 
using  Menu  Selection  Sequence  1.4.1.  (2)  It  may  be  generated 

’automatically'  by  the  OHMIS  program  whenever  a  'suspense  applicability 
data  generating  requirement1  is  found  to  be  applicable.  (See 
requirement  description  data  (DS1)  for  a  description  of  the  meaning  of  a 
'suspense  applicability  data  generating  requirement'.) 

With  the  exception  of  Reminder  Notice  type  suspense  data  (see  below), 
historical  DS4  data  is  maintained  in  order  to  have  an  audit  trail  of 
what  requirements  were  in  effect.  0S4  data  cannot  be  changed  or 
deleted.  If  DS4  data  should  be  changed  or  should  no  longer  be  used 
before  the  "last  suspense  date"  (end  date)  on  the  requirement,  the 
user  may  cancel  the  suspense  date  by  entering  a  deactivation  date  for 
the  requirement. 

1.  Requirement  application  identifier  (ID5).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS4  data. 

2.  OHMIS  service  area  identifier  ( I DIO )  for  the  service  area 
covered  by  this  application  of  the  requirement.  The  program 
will  only  look  for  applicability  data  for  requirements  for 
the  OHMIS  service  area  of  the  user  which  triggered  the 
requirements  suspense  check,  i.e.,  the  user  who  had  logged 
onto  the  system  at  the  time  that  the  daily  requirement 
suspense  check  is  to  be  conducted.  The  OHMIS  service  area 
identified  (1010)  is  supplied  by  the  user  when  entering  the 
DS4  data;  normally,  it  would  be  the  same  I DIO  as  the  service 
area  to  which  the  user  generating  the  requirement  belongs. 
However,  this  is  not  necessarily  the  case.  For  example, 
requirements  applicability  data  may  be  generated  at  the  DA 
level  for  an  individual  OHMIS  service  area. 


For  DS4  data  generated  from  'suspense  applicability  data 
generating  requirements',  the  ID10  would  be  the  same  as  the 
ID10  on  the  information  triggered  requirements  applicability 
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data  (DS3)  or  the  allowable  limits  specifications 
requirements  applicability  data  (DS17)  which  found  the 
suspense  applicability  data  generating  requirement  (DS1)  that 
generated  the  DS4  data  to  be  applicable,  i.e.,  that  triggered 
,  the  requirement  which  in  turn  generated  the  DS4  data. 

3.  Identifier  of  the  organizational  level  to  which  this 
requirement  applies.  (See  DS3  data  for  explanation  of  this 
data  element.  Not  used  in  Reminder  Notice  type  of  suspense 
data.)  For  DS4  data  generated  from  'suspense  applicability 
data  generating  requirements',  the  identifier  would  be  the 
same  as  that  given  in  the  DS3  data  or  DS17  data  that 
triggered  the  suspense  applicability  data  generating 
requirement. 

4.  Whether  this  suspense  data  is  to  be  used  for  requirement' 
implementation  monitoring  as  distinguished  from  simply  b  ; 
used  to  generate  “reminder  notice"  type  of  suspenses. 

Answer:  Yes/No.  The  primary  purpose  of  DS4  data  is  to 
track  of  requirements  (recommendations)  that  are  to  be  done 
on  a  certain  date  (e.g.,  annual  Industrial  Hygiene  Surveys  of 
a  facility,  biannual  hearing  tests  of  employees).  However, 
because  the  data  processing  is  very  similar,  the  user  will  be 
allowed  to  use  this  same  DS4  data  to  generate  a  "reminder 
notice"  to  remind  the  user  of  an  event  or  action  that  is  not 

,  linked  to  a  requirement.  If  this  is  the  use  that  is  being 

made  of  this  particular  execution  of  suspense  data,  the  user 
would  enter  a  'No'.  For  DS4  data  generated  from  'suspense 
!  applicability  data  generating  requirements',  the  answer  would 

be  ' Yes  ' . 

; 

.  If  this  is  Reminder  Notice  type  of  suspense  data,  the  program 

}  will  operate  differently  in  several  ways:  Several  of  the 

suspense  data  elements  are  not  requested  if  the  user  has 
answered  'No*  in  this  field.  Also,  the  requirements 
implementation  data  (DS5)  will  be  shown  on  a  Reminder  Notice 
List  (05),  rather  than  an  Outstanding  Requirements  List  (04) 
and  a  Requirement  Notification  and  Certification  Record  (03). 

j  Also,  neither  the  DS4  data  nor  the  requirements 

'  implementation  data  (DS5)  for  Reminder  Notice  type  suspense 

data  will  be  archived.  Historical  requirements  DS4  and  DS5 
1  data  is  maintained  in  OHMIS  in  order  to  provide  an  audit 

i  trail,  but  historical  data  on  Reminder  Notices  is  not 

maintained.  This  is  because  it  is  expected  that  if  an  action 
is  not  related  to  a  requirement,  it  will  not  be  of  sufficient 
significance  to  maintain  historical  data  on  it.  The  DS5  data 
for  a  Reminder  Notice  type  of  date  triggered  action  is 
deleted  when  the  disposition  data  (i.e.,  the  date  and  type  of 
disposition  of  the  action  entered  in  Menu  Sequence  1.5.3; 
Function  F28)  is  entered  by  the  user  for  that  set  of  DS5 
data.  The  set  of  Reminder  Notice  type  of  DS4  data  that 
corresponds  to  the  DS5  data  is  deleted  when  the  DS5  data  has 
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been  deleted  and  the  "deactivation  date"  on  the  DS4  data  has 
been  filled. 

5.  QHMIS  requirement  identifier  (ID6)  for  the  type  of 
requirement  which  this  set  of  suspense  data  is  going  to 
trigger.  The  requirement  identifier  (ID6)  links  the  DS4  data 
to  the  requirement  (recommendation)  description  data.  This 
field  will  be  left  blank  if  this  is  a  Reminder  Notice  type  of 
suspense  data.  For  DS4  data  generated  from  'suspense 
applicability  data  generating  requirements',  the  106  is  the 
106  on  the  ‘suspense  applicability  data  generating 
requirement'  which  generated  this  DS4  data. 

6.  Supplement  to  the  requirement  description.  This  field 
provides  any  additional  explanation  of  the  requirement  beyond 
that  given  in  the  requirement  description  data  (DS1);  it  is 
used  to  explain  this  particular  execution  of  the  requirement. 
It  would  be  used  in  place  of  the  requirement  description 
given  on  the  DS1  data  with  the  above  requirement  identifier 
(ID6)  for  Reminder  Notice  type  suspense  data,  i.e.,  this 
field  describes  the  Reminder  Notice  action,  because  for 
Reminder  Notice  type  suspense  data  there  will  be  no  DS1  data 
to  describe  the  requirement.  It  may  be  left  blank  or  used 
for  requirement  type  suspense  data.  For  DS4  data  generated 
from  'suspense  applicability  data  generating  requirements’, 
this  description  would  be  copied  from  the  DS3  data  or  DS17 
data  tnat  triggered  the  'suspense  applicability  data 
generating  requirement'. 

7.  Task  type  code  (CT8)  that  describes  the  action  specified  in 
this  DS4  data.  For  Reminder  Notice  type  of  DS4  data,  this 
field  is  supplied  by  the  user,  if  applicable;  for  all  other 
DS4  data  (including  requirement  type  DS4  data  and  D54  data 
generated  by  suspense  applicability  data  generating 
requirements),  this  information  is  obtained  from  the  0S1  data 
referenced  by  the  106  above.  However,  it  may  be  left  blank 
on  the  DS4  data  (or  have  been  left  blank  on  the  DS1  data)  if 
the  type  of  action  that  is  to  be  triggered  by  this 
requirement  is  not  a  "schedu  leab  le"  type  of  action,  i.e.,  not 
an  action  that  the  OHMIS  scheduli  g  program  (Function  F4)  is 
to  schedule. 

8.  Description  of  any  additional  checks  tnat  the  user  should 
exercise  to  determine  whether  the  requirement  is  applicable 
and  should  be  implemented,  beyond  tnose  checks  specified  by 
this  suspense  data.  (See  DS3  for  further  explanations  of  the 
use  of  additional  checks.)  This  field  is  not  used  for 
Reminder  Notice  type  of  suspense  data.  For  DS4  data 
generated  from  'suspense  applicability  data  generating 
requirements',  this  description  would  be  copied  from  the  0S3 
data  or  OS  1 7  data  that  triggered  tne  'suspense  applicability 
data  generating  requirement'. 
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9.  Description  of  the  Menu  Selection  Sequence,  if  any,  for 

undertaking  the  data  processing  actions  associated  with  the 
above  referenced  additional  checks.  For  DS4  data  generated 
from  'suspense  applicability  data  generating  requirements', 
this  description  would  be  copied  from  the  DS3  data  or  DS17 
data  that  triggered  the  'suspense  applicability  data 
generating  requirement*. 

10  Identifier  type  codes  (CT10)  or  data  element  type  codes 

(CT4)  and  for  the  requirement  implementation  unit  types  1-5. 
This  identifier  types  (or  data  element  types)  describe  the 
type  of  unit  (or  set  of  units)  to  which  this  application  of 
the  requirement  is  to  apply.  For  example,  a  requirement  to 
conduct  annual  medical  surveillance  on  an  employee  would  have 
an  employee  as  the  type  of  unit  to  which  this  requirement  is 
to  apply,  i.e.,  the  identifier  type  would  be  “ employee." 

There  may  be  up  to  five  requirement  implementation  units  if 
the  requirement  refers  to  a  set  of  units.  This  data  may  be 
left  blank. 

For  DS4  data  generated  from  'suspense  applicability  data 
generating  requirements',  the  requirement  implementation  unit 
types  are  known  from  the  DS3  data  or  DS17  data  that  triggered 
the  suspense  appl icabil ity  data  generating  requirements 
(DS1).  For  DS4  data  generated  for  a  requirement  triggered  by 
DS3  data,  the  requirement  implementation  unit  types  are  given 
on  the  triggering  step  requirement  implementation  unit 
identifier  types  data  (DS6)  corresponding  to  the  triggering 
step  given  on  the  DS3  data.  For  DS4  data  generated  from 
requirements  triggered  by  DS17  data,  the  requirement 
implementation  unit  types  are  obtained  from  the  DS17  data. 

11.  Identifiers  or  values  of  the  above  referenced  identifier 

types  (of  data  element  types)  for  requirement  unit  types  1-5. 
These  are  the  single  identifiers  (or  values),  not  ranges  of 
values,  for  each  of  the  requirement  implementation  unit  types 
identified  above.  For  example,  if  the  requirement 
implementation  unit  type  identified  above  was  an  employee, 
the  data  in  this  field  would  specify  a  particular  enployee 
identifier  (ID4)  for  which  this  application  of  the 
requirement  is  to  be  monitored,  e.g.,  the  identity  of  the 
specific  employee  for  whom  the  next  suspense  date  for 
implementing  medical  surveillance  is  to  be  monitored.  This 
data  may  be  left  blank.  For  DS4  data  generated  from 
'suspense  applicability  data  generating  requirements',  the 
identifiers  or  values  for  the  requirement  implementation 
units  are  known  by  the  DS3  data  or  DS17  data  that  triggered 
the  'suspense  applicability  data  generating  requirement'. 

For  DS4  data  generated  from  a  requirement  triggered  by  DS3 
data,  the  identifiers  or  values  for  the  requirement 
implementation  units  come  from  the  requirements  check  request 
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data  (DS2)  that  was  generated  by  the  triggering  step  that 
resulted  in  the  check  of  the  DS3  data  for  applicable 
requirements.  For  DS4  data  generated  from  a  requirement 
triggered  by  DS17  data,  the  identifiers  or  values  for  the 
requirement  implementation  units  come  from  the  allowable 
limits  check  request  data  (DS18)  that  was  generated  at  the 
time  that  the  evaluation  of  allowable  limits  that  identified 
the  DS17  data  was  made. 

12.  The  employee  identifier  (ID4)  and  QHMIS  user  identifier 

( ID13)  for  the  person  prescribing  this  application  of  the 
requirement.  For  DS4  data  generated  from  'suspense 
applicability  data  generating  requirements ' ,  this  description 
would  be  copied  from  the  DS3  data  or  DS17  data  that  triggered 
the  'suspense  applicability  data  generating  requirement'. 

13.  The  QHMIS  user  identifier  (ID3)  or  QHMIS  position  identifier 
( ID14)  for  the  user/position  of  the  person  who  is  to 
execute  the  requirement,  i.e.,  the  primary  person  who  is 

to  be  notified  of  the  requirement.  (See  DS3  data  for  further 
explanation  of  this  field.)  For  DS4  data  generated  from 
'suspense  applicability  data  generating  requirements',  this 
description  would  be  copied  from  the  DS3  data  or  DS17  data 
that  triggered  the  'suspense  applicability  data  generating 
requirement' . 

14.  The  QHMIS  user  identifier  (ID13)  or  QHMIS  position 
identifier  (ID14)  (or,  if  not  a  user/position,  the  employee 
identifier  ( ID4)) ,  for  the  management  person,  if  any,  who 
should  be  notified  of  the  requirement  in  order  to  supervise 
the  execution  of  the  requirement.  (See  DS3  data  for  further 
explanation  of  this  field.  Not  used  in  Reminder  Notice  type 
of  suspense  data.)  For  DS4  data  generated  from  'suspense 
applicability  data  generating  requirements',  this  description 
would  be  copied  from  the  DS3  data  or  DS17  data  that  triggered 
the  ‘suspense  applicability  data  generating  requirement'. 

15 .  The  QHMIS  user  identifier  (ID13)  or  the  QHMIS  position 
identifier  (ID14)  (or,  if  not  a  user/position,  the  employee 
identifier  (ID4)),  of  the  person,  if  any,  who  must  approve 
the  disposition  of  the  requirement.  (See  the  DS3  data  for 
further  explanation  of  this  field)  Not  used  in  Reminder 
Notice  type  of  suspense  data.  For  DS4  data  generated  from 
'suspense  applicability  data  generating  requirements',  this 
description  would  be  copied  from  the  DS3  data  or  DS17  data 
that  triggered  the  'suspense  applicability  data  generating 
requirement' . 

16.  Whether  this  application  of  the  requirement  is  to  be 
implemented  more  than  once.  Answers:  Yes  (periodical ly 
triggered  requirements)  or  No  (one-time  triggered 
requirements) .  For  DS4  data  generated  from  'suspense 
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applicability  data  generating  requirements',  this  field  comes 
from  the  DS1  data  corresponding  to  the  ID6  given  above. 

17.  First  suspense  date,  i.e.,  first  date  that  the  requirement 

is  to  be  implemented.  This  date  is  supplied  by  the  user.  If 
it  is  a  one-time  triggered  requirement,  this  would  be  the  one 
date  on  which  the  requirement  is  to  be  triggered.  If  it  is  a 
periodically  triggered  requirement,  this  date  would  be  the 
first  of  the  several  dates  on  which  this  requirement  is  to  be 
triggered.  For  DS4  data  generated  from  'suspense 
applicability  data  generating  requirements',  this  date  is 
calculated  by  adding  the  amount  of  days  until  the  'first 
suspense  date'  (from  the  current  date)  that  is  provided  on 
the  DS1  data  corresponding  to  the  ID6  given  above. 

18.  Last  suspense  date,  i.e.,  the  last  date  that  this 
requirement  is  to  be  triggered.  This  date  indicates  how  long 
a  periodically  triggered  requirement  is  to  be  triggered, 
e.g.,  for  a  requirement  that  is  to  be  triggered  every  month 
for  six  months,  the  user  would  enter  as  a  "last  suspense 
date"  the  date  that  is  six  months  from  the  "first  suspense 
date."  For  some  periodic  requirements  (including  all  those 
for  which  the  DS4  data  is  generated  by  a  suspense 
applicability  data  generating  requirement),  the  requirement 
description  data  (DS1)  will  have  specified  the  period  of  time 
that  the  requirement  must  be  executed;  this  data  will  be  used 
by  the  program  to  calculate  a  "last  suspense  date"  for  the 
user  (based  on  the  first  suspense  date).  If  the  user  wishes 
to  override  the  DS1  specified  last  suspense  date,  this 
variance  from  the  requirement  and  the  reason  for  the  variance 
is  also  indicated  in  this  field  as  well  as  the  last  suspense 
date.  For  mandatory  requirements,  the  DS1  specified  last 
suspense  date  must  be  used.  The  DS4  entry  program  (Menu 
Selection  Sequence  1.4.1)  will  check  for  internal  consistency 
between  the  DS1  data  and  the  DS4  data. 

The  last  suspense  date  is  automatically  filled  in  the  same  as 
the  "first  suspense  date,"  if  this  is  a  one-time  triggered 
requirement.  The  last  suspense  date  may  be  left  blank  for 
periodically  triggered  requirements  if  the  user  wishes  the 
requirement  to  be  periodically  implemented  for  an  indefinite 
period  of  time.  When  this  last  suspense  date  is  reached,  the 
DS4  data  is  considered  to  be  deactivated  (i.e.,  the 
deactivation  date  is  filled  in  with  the  current  date  by  the 
OHMIS  program  as  a  part  of  the  suspense  check  function 
(Function  F1A)).  For  Reminder  Notice  type  of  suspense  data, 
once  the  DS4  data  has  been  deactivated  and  the  last 
requirement  implementation  data  (DS5)  has  been  generated  and 
executed  (i.e.,  all  disposition  data  has  been  entered  on  the 
0S5  data),  the  DS4  data  is  deleted. 
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19.  The  deactivation  date.  This  date  is  completed  when  the  DS4 
data  is  no  longer  active.  The  program  may  fill  in  this  date 
automatically  once  the  calculated  "next  date"  is  found  to  be 
later  than  the  "last  suspense  date"  in  the  suspense  check 
function  (Function  F1A);  or,  if  the  user  wishes  to  cancel  a 
set  of  0S4  data,  s/he  may  fill  in  the  deactivation  date  using 
Menu  Selection  Sequence  1.4.4. 

20.  The  OHMIS  user  identifier  ( I Dl 3 )  of  the  person  who  approved 
the  cancellation  (deactivation)  of  this  set  of  DS4  data. 

This  field  would  be  the  same  as  the  person  who  promulgated 
this  application  of  the  requirement  if  the  last  suspense  date 
is  entered  at  the  same  time  as  the  DS4  data  was  entered  and 
the  last  suspense  date  (not  an  intervening  cancellation  date) 
was  used  as  the  deactivation  date  for  the  requirement. 

21.  The  employee  identifier  (ID4)  for  the  above  person. 

22.  Prior  notification  time,  i.e.,  the  amount  of  time  prior  to 
the  suspense  date  (due  date)  that  the  generation  of  a  notice 
about  the  need  to  execute  the  requirement  (or  a  Reminder 
Notice)  should  be  triggered.  The  value  in  this  field  may  be 
"0",  if  there  is  no  need  for  a  prior  notification  time 
period,  i.e.,  the  requirement  can  be  executed  on  the  day  that 
the  person  is  notified  that  the  requirement  has  come  due. 

For  DS4  data  generated  from  'suspense  applicability  data 
generating  requirements',  this  field  comes  from  the  DS1  data 
corresponding  to  the  ID6  given  above. 

23.  Suspense  interval,  i.e.,  interval  of  time  between  suspense 
dates  for  periodically  triggered  requirements,  e.g.,  this 
requirement  is  to  be  triggered  once  every  two  months.  For 
DS4  generated  by  suspense  applicability  data  generation 
requirements,  this  length  of  time  will  be  specified  in  the 
requirement  description  data  (DS1);  for  DS4  data  entered  by 
the  user,  this  length  of  time  may  be  specified  in  the  DS1 
data  or  by  the  user.  The  DSl  specified  interval,  if  any  has 
been  provided,  will  be  used  unless  the  user  specifies  that 
the  DSl  interval  is  to  be  overridden.  In  that  case,  the 
interval  is  supplied  by  the  user  along  with  the  reason  why 
the  interval  was  overridden.  The  DS4  entry  program  (Menu 
Selection  Sequence  1.4.1)  checks  that  the  DSl  data  and  the 
DS4  data  are  internally  consistent.  For  mandatory 
requirements  the  user  must  use  the  DSl  specified  interval,  if 
any  has  been  specified. 

24.  Next  suspense  date,  i.e.,  next  date,  this  suspense  is  to  be 
triggered.  This  date  is  supplied  by  the  program  as  a  part  of 
the  suspense  check  (Function  F1A).  For  the  first  time  this 
requirement  is  to  be  implemented,  the  "next  date"  is  the  same 
as  the  "first  suspense  date,"  minus  the  "prior  notification 
time."  At  the  time  that  the  program  makes  a  suspense 
requirements  check  (Step  F1A-2)  to  see  what  requirements  have 
come  due  and  finds  this  suspense  to  be  due,  the  program 
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updates  the  "next  date,"  the  algorithm  being:  the  old  "next 
date"  plus  the  suspense  interval  with  a  check  to  determine 
that  the  new  "next  date"  is  not  later  than  the  "last  suspense 
date,"  in  which  case  the  suspense  is  treated  as  though  the 
"last  suspense  date"  has  been  reached,  i.e.,  the  suspense 
data  is  deactivated  and  the  old  "next  date"  remains  on  the 
DS4  data.  In  the  case  of  Reminder  Notice  type  of  suspense 
data,  the  DS4  data  is  not  deleted  until  the  disposition  data 
has  been  entered  for  the  DS5  data  generated  by  the  current 
triggering  of  a  requirement,  i.e.,  the  triggering  that 
resulted  in  the  comparison  of  the  "next  date"  and  the  "last 
suspense  date." 
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Requirements  Implementation  Data 


This  data  describes  the  details  of  a  requirement  (or  recommendation) 
that  has  been  triggered  by  the  OHMIS  program;  it  is  also  used  to 
describe  the  details  of  Reminder  Notices,  i.e.  nonrequirements  triggered 
by  a  suspense  date.  "Triggered"  means  that  the  program  has  determined 
that  an  action  is  required  (recommended),  i.e.,  that  a  particular 
requirement  (recommendation)  is  applicable  or  due.  The  DS5  data  is  used 
to  monitor  the  execution  of  the  required  (recommended)  action  and  to 
provide  a  record  of  the  disposition  of  the  requirement  (recommendation). 

DS5  data  is  generated  by  the  program  from  one  of  three  types  of  data: 

o  (Information  triggered)  requirements  applicability  data 

(DS3) .  A  requirement  can  be  triggered  when  certain  parts  of 
the  OHMIS  program,  referred  to  as  triggering  steps,  are 
executed.  Triggering  steps  are  primarily  data  entry  program 
steps.  When  the  triggering  step  is  executed,  the  program 
determines  whether  the  data  entered  in  the  triggering  step 
matches  the  0S3  data;  if  it  does  a  requirement  is  triggered 
and  the  0S5  data  for  the  requirement  specified  in  the  DS3 
data  is  generated.  Thus  the  DS3  data  is  referred  to  as 
information  triggered  requirements  applicability  data 
because  it  is  the  entry  of  information  at  a  triggering  step 
that  results  in  a  check  to  determine  whether  a  requirement  is 
applicable,  and  if  the  requirement  is  applicable,  the 
triggering  of  a  requirement  through  the  generation  of  DS5 
data. 

o  Requirements  Suspense  Data  (DS4).  A  requirement  can  be 
triggered  by  the  arrival  of  a  "due  date."  Due  dates  are 
shown  on  DS4  data.  The  OHMIS  program  checks  periodically  to 
determine  if  a  due  date  has  arrived,  i.e.  if  the  current  date 
matches  the  "next  suspense  date"  information  on  the  DS4  data. 
If  it  has  arrived,  DS5  data  is  generated  to  monitor  the 
requirement  that  DS4  data  specifies  is  to  be  executed  on  the 
due  date.  DS4  data  can  also  be  used  as  simply  a  Reminder 
Notice  system;  that  is,  a  suspense  date  "tickler  file"  for 
nonrequirements.  DS5  data  is  generated  in  the  same  way  for 
Reminder  Notice  type  suspense  data  as  it  is  for  requirement 
(recommendation)  suspense  data. 

o  Allowable  limits  specification  data  (DS17).  A  requirement 
can  be  triggered  by  the  entry  of  data  from  an  OHMIS  form 
(i.e.,  completed  forms  data  (DS14 ) )  that  is  found  to  match  an 
allowable  (or  unallowable)  limit  specified  on  a  set  of  DS17 
data.  Whenever  such  a  match  is  found  for  the  requirement 
specified,  the  DS17  data  is  generated. 

DS5  data  is  used  to  monitor  the  execution  of  the  requirement  by  telling 
the  user  of  a  requirement  using  the  Outstanding  Requirements  Lists  (04) 
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and  the  Requirement  Notification  and  Certification  Record  (03)  (or  the 
Reminder  Notice  List  (05))  and  by  allowing  the  user  to  enter  data  on  the 
disposition  of  the  requirement,  i.e.,  information  about  the  completion 
of  the  requirement,  using  Menu  Selection  Sequence  1.5.3  (Function  F2B). 

With  the  exception  of  the  disposition  data  part  of  the  DS5  data,  DS5 
data  is  not  entered  by  the  user,  but  is  generated  by  the  OHMIS  program 
whenever  a  requirement  is  found  to  be  applicable  through:  (1)  checking 
the  DS3  data  during  the  execution  of  a  triggering  step  or  during  a 
requirements  check  (Menu  Selection  Sequence  1.2.3  (Function  F2A) ; 
requirements  checks  are  manual,  i.e.  user  conducted,  checks  of  DS3  data 
which  follow  a  triggering  step,  if  the  OHMIS  program  is  not  able  to 
automatical ly  determine  whether  there  is  a  set  of  applicable  DS3  data 
corresponding  to  the  data  entered  during  the  triggering  step);  (2) 
checking  the  DS4  data  during  a  requirements  suspense  check  (see  Function 
F1A);  or,  (3)  checking  the  DS17  data  during  the  entry  of  DS14  data  from 
a  completed  OHMIS  form  (Menu  Selection  Sequence  3.1;  Function  F3B)  or 
during  an  allowable  limits  check  (Menu  Selection  Sequence  4.4.4; 
(Function  F3C);  an  allowable  limits  check  is  executed  manual ly,  i.e. 
by  the  user,  when  the  OHMIS  program  is  not  able  to  determine 
automatically  whether  or  not  a  match  to  a  specified  allowable  limit 
has  been  entered  on  an  OHMIS  form).  For  information  triggered 
requirements  (based  on  DS3  data)  and  allowable  limit  triggered 
requirements  (based  on  DS17  data)  the  user  may  need  to  enter  part  of 
the  DS5  data  during  the  requirements  check  (Menu  Selection  1.2.3; 
Function  F2A)  or  the  allowable  limits  check  (Menu  Selection  Sequence 
4.4.4;  Function  F3C),  if  not  all  of  the  data  needed  to  determine  whether 
a  requirement  is  applicable  is  available  in  the  current  OHMIS  data  base 
at  the  time  of  the  execution  of  the  triggering  steps  (for  DS3  data)  or 
at  the  time  of  the  entry  of  the  completed  forms  data  (for  DS17  data). 
Otherwise,  and  for  all  date  triggered  requirements  (based  on  DS4  data), 
the  program  automatically  (i.e.,  without  user  input)  generates  the  DS5 
data  when  it  is  triggered. 

The  disposition  data  part  of  the  DS5  data  is  entered  by  the  user  using 
Menu  Selection  Sequence  1.5.3  (Function  F2B).  Historical  DS5  data  is 
maintained.  The  DS5  data  cannot  be  deleted  and  only  the  disposition 
part  of  the  DS5  data  can  be  changed  (Menu  Selection  Sequence  1.5.5). 

The  values  data  determining  the  applicability  of  a  requirement  (i.e., 
either  the  requirements  check  request  data  (DS2)  and  values  data  for 
requirements  applicability  characteristics  (DS8)  for  information 
triggered  requirements;  or,  the  allowable  limits  check  request  data 
(DS18)  for  allowable  limits  triggered  requirements)  is  used  in 
generating  DS5  data  and  is  deleted  when  the  DS5  data  is  generated. 

At  the  same  time  that  the  DS5  data  is  generated,  the  requirement 
implementation  identifier  (ID9)  is  entered  onto  the  Outstanding 
Requirements  Lists  (04  and  0L3)  to  be  used  to  remind  the  user  that  there 
is  an  outstanding  (unexecuted)  requirement. 
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Also,  immediately  following  the  generation  of  DS5  data,  the  program 
checks  to  determine  whether  the  requirement  being  implemented  by  the  DS5 
data  refers  to  a  specified  task,  i.e.,  whether  the  requirement 
description  data  (DS1)  for  the  requirement  covered  by  this  DS5  data 
contains  a  task  type  code  (CT8)  specifying  the  type  of  task  that  is 
involved  in  executing  the  requirement.  If  there  is  such  a  task  type 
code  (CT8)  on  the  DS1  data,  the  program  will  ' automatically '  schedule 
the  task  in  Function  F4A,  i.e.,  the  program  schedules  the  execution  of 
the  requirement  by  generating  a  set  of  specific  task  scheduling  data 
(DS24)  for  the  task  and  scheduling  this  task  through  putting  the  task 
identifier  (1023)  for  the  DS24  data  into  the  needed  time  slots  on  a  set 
of  monthly  schedule  data  (DS27).  The  scheduling  of  the  task  is  done  by 
putting  the  requirement  implementation  identifier  ( ID9)  for  the  newly 
generated  set  of  DS5  data  onto  the  list  of  requirement  implementation 
identifiers  for  requirements  having  tasks  that  need  to  be  scheduled  by 
OHMIS  service  area  (DL35).  Each  day  that  a  user  logs  onto  the  OHMIS 
system  (Function  F1A),  the  OHMIS  program  checks  to  determine  if  there 
are  any  entries  on  the  DL35  list  for  the  OHMIS  service  area  of  the  user 
who  logged  on.  If  there  are,  the  OHMIS  program  goes  to  Function  F4A  and 
schedules  those  tasks  on  the  DL35  list. 

1.  Requirement  implementation  identifier  (ID9).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS5  data. 

2.  Document  identifier  (ID3)  for  the  Requirement  Notification 
and  Certification  Record  (03)  on  which  the  hard  copy  of  the 
disposition  of  the  requirement  is  to  be  stored.  The  03 
output  is  not  only  a  notification  to  the  use  of  a 
requirement,  but  can  also  become  the  hard  copy  on  which  the 
signatures  of  the  person  who  executed  and  approved  the 
execution  of  the  requirement  are  stored  (for  those 
requirements  of  sufficient  significance  that  a  record  of 
these  signatures  should  be  maintained).  In  order  to  identify 
the  03  record  on  which  this  information  is  stored,  the 
program  assigns  a  document  identifier  (ID3)  for  each 
implementation  of  a  requirement.  This  identifier  is  printed 
out  on  the  03  record.  The  identifier  is  assigned  at  the  time 
that  the  DS5  data  is  generated  in  order  that  the  same 
document  identifier  will  appear  on  every  generation  of  the 
Requirement  Notification  and  Certification  Record  (03)  for 
the  same  requirement  made;  this  output  could  be  generated 
several  times  before  the  requirement  is  executed.  No 
document  identifier  is  assigned  for  Reminder  Notice 
(nonrequirement)  types  of  DS5  data. 

3.  The  requirement  application  identifier  (ID5)  for  the 
particular  set  of  information  triggered  requirements 
applicability  data  (DS3),  requirements  suspense  data  (DS4)  or 
allowable  limits  specif ication  data  (DS17)  that  triggered 
this  implementation  of  the  requirement.  This  identifier 
links  the  DS5  data  to  the  other  data  about  the  implementation 
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of  the  requirement  given  on  the  corresponding  DS3,  DS4,  or 
DS17  data. 

The  type  of  trigger  that  generated  this  set  of  DS5  data. 
Whether  the  above  ID5  is  for:  (1)  an  information  triggered 
requirement  (triggered  by  DS3  data);  (2)  a  date  triggered 
requirement  (triggered  by  DS4  data  for  a  requirement);  (3)  a 
Reminder  Notice  (nonrequirement  triggered  by  DS4  data);  (4) 
an  allowable  limits  triggered  requirement  (triggered  by  DS17 
data)  for  an  allowable  limits  specification  made  for  a  forms 
subpart  (i.e.,  an  allowable  limit  for  a  set  of  up  to  six  data 
elements  on  a  form);  or  (5)  an  allowable  limits  triggered 
requirement  (triggered  by  DS17  data)  for  an  allowable  limits 
specification  made  about  the  entry  of  a  form-as-a-whole 
(i.e.,  an  allowable  limit  made  about  the  number  of  times  that 
a  particular  type  of  form  can  be  entered  onto  the  OHMIS 
system  for  a  particular  unit;  as  when  the  entry  of  too  many 
reports  of  hazardous  substance  spills  for  a  given  facility  is 
to  trigger  a  requirement). 

OHMIS  requirement  identifier  (ID6)  for  the  requirement  that 
is  to  be  implemented  and  monitored  by  this  set  of  DS5  data. 
Comes  from  the  DS3,  0S4,  or  DSl7  data  corresponding  to  the 
above  ID5.  Left  blank  if  this  DS5  data  is  generated  from 
Reminder  Notice  type  suspense  data. 

The  OHMIS  service  area  identifier  (ID10)  for  the  service 
area  in  which  this  requirement  implementation  originated. 

From  DS3,  DS4,  or  DS17  data.  Used  by  the  program  to  quickly 
identify  all  implementations  of  requirements  for  a  given 
OHMIS  service  area. 

Date  on  which  this  requirement  was  triggered,  i.e.,  date 
this  set  of  DS5  data  was  generated.  For  information 
triggered  requirements,  this  is  the  date  that  the 
requirement  check  was  made,  i.e.,  the  date  that  the 
triggering  step  was  executed,  if  the  DS5  data  was  generated 
automatically  from  the  DS3  data;  or,  the  date  that  the  user 
supplied  the  remaining  information  needed  to  determine  if  a 
requirement  was  applicable  during  a  requirements  check  (Menu 
Selection  Sequence  1.2.3;  Function  F2A).  For  al lowable 
limits  triggered  requirements,  this  is  the  date  that  an 
allowable  limit  evaluation  was  made,  i.e.,  the  date  that  the 
data  from  a  completed  OHMIS  form  (DS14  data)  that  matched  the 
allowable  limits  on  the  DS17  data  was  entered  onto  the  OHMIS 
system,  if  the  DS5  data  was  generated  automatically  form  the 
DS17  data;  or,  the  date  that  the  user  supplied  the  remaining 
information  needed  to  determine  which  allowable  limit  was 
applicable  during  a  allowable  limits  check  (Menu  Selection 
Sequence  4.4.4;  Function  F3C).  For  date  triggered 
requirements,  this  is  the  date  that  the  OHMIS  ' log  on' 
program  (Function  F1A)  found  that  a  set  of  DS4  data  had  a  due 
date  that  matched  the  current  date,  i.e.,  found  that  the 
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current  date  was  equal  to  or  later  than  the  due  date  minus 
the  prior  notification  time  period  on  the  DS4  data.  (This  is 
referred  to  as  the  "next  suspense  date"  on  the  DS4  data.) 


8.  Requirement  due  date.  The  date  that  the  requirement  is 
due,  if  any.  This  field  is  completed  in  several  ways: 

(1)  If  this  set  of  DS5  date  triggered  (i.e.,  generated  from 
DS4  data),  then  the  due  date  for  the  requirement  is  the 
'next  suspense  date'  plus  the  'prior  notification  time' 
given  on  the  DS4  data. 


(2)  If  this  set  of  DS5  data  is  from  a  requirement  with  a 
task  type  code  (CT8)  specified  in  the  requirement 
description  data  (DS1)  corresponding  to  the  requirement 
identifier  (ID6)  for  which  this  is  the  requirement 
implementation  data  (DS5)  (i.e.,  the  ID6  given  below), 
then  the  due  date  for  the  requirement  (as 
distinguished  from  the  due  date  for  the  task)  is: 

(a)  The  current  date  plus  the  length  of  time  required 
(recommended)  to  complete  the  requirement  given  in 
the  DS1  data;  or, 

(b)  The  current  date  plus  the  length  of  time  allowed 
to  complete  this  task  (as  specified  in  the  task 
type  description  data  (DS23)  corresponding  to  the 
task  type  code  (CT8)  given  below)  whichever  is 
later.  Note:  The  due  date  for  the  requirement 
need not  be  the  same  as  the  due  date  for  the  task 
triggered  by  this  requirement,  because  the 
requirement  could  involve  more  than  completing  the 
task;  however,  the  due  date  for  the  requirement 
cannot  be  before  the  due  date  for  the  task 
triggered  by  the  requirement. 

9.  Requirements  check  request  identifier  (ID1)  or  allowable 

limits  check  request  identifier  (ID22)  for  the  requirements 
check  under  which  this  set  of  DS5  data  was  generated  (for 
information  triggered  requirements)  or  the  allowable  limits 
check  or  evaluation  under  which  this  set  of  DS5  data  was 
generated  (for  allowable  limits  triggered  requirements).  An 
ID1  corresponds  to  a  set  of  requirements  check  request  data 
(DS2);  an  ID22  corresponds  to  a  set  of  allowable  limits  check 
request  data  (DS18).  The  DS2  or  DS 18  data  is  deleted  when 
the  DS5  data  is  generated. 


10.  Values  for  the  requirement  implementation  units,  i.e.,  the 
unit(s)  to  which  the  requirement  applies.  These  are  the  up 
to  5  requirement  implementation  units  (for  DS3  or  DS4  data); 
or,  the  up  to  6  forms  units  for  allowable  limits  applicable 
to  forms  subparts  that  have  been  designated  as  requirement 
implementation  units,  or,  the  up  to  9  forms  units  for 
allowable  limits  applicable  to  forms-as-a-whole  that  have 
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been  designated  as  requirement  implementation  units  (for  OS 1 7 
data).  Requirement  implementation  units  indicate  to  what 
unit  or  combination  of  units  the  requirement  applies.  The 
values  for  the  requirement  implementation  units  for 
information  triggered  requirements  come  from  the  DS2  data 
corresponding  to  the  above  ID1.  The  values  for  the  date 
triggered  requirements  implementation  units  come  from  the  DS4 
data  corresponding  to  the  above  ID5.  The  values  for  the 
forms  units  designated  as  requirement  implementation  units 
for  allowable  limits  triggered  requirements  come  from  the 
DS18  data  corresponding  to  the  above  ID22. 

11.  Values  for  the  applicability  characteristics  (factors) 
determining  which  requirement  is  applicable.  There  are  no 
applicability  factors  data  for  date  triggered  requirements. 
For  information  triggered  requirements  these  factors  come 
from  the  values  data  for  requirements  applicability 
characteristics  (DS8)  corresponding  to  the  above  IDl.  (The 
DS8  data  is  deleted  when  the  DS5  data  is  generated)  For 
allowable  limits  triggered  requirements  these  values  come 
from  the  allowable  limits  check  request  data  (DS18) 
corresponding  to  the  above  ID 22. 

12.  Completed  forms  identifier  (ID18)  for  the  form  containing 
the  data  entered  onto  the  OHMIS  system  that  triggered  an 
allowable  limits  requirement.  This  is  the  first  ID18  on  the 
DS18  data  corresponding  to  the  1022  given  above.  Used  only 
for  allowable  limits  triggered  requirements. 

13.  The  completed  forms  identified s)  (ID18)  for  the  form(s) 
containing  the  base  line  values  used  in  the  allowable  limits 
evaluation  that  triggered  this  set  of  DS5  data  to  determine 
whether  the  values  entered  on  the  completed  forms  data  (DS14) 
match  the  prescribed  allowable  limits.  This  is  only  used  for 
DS5  data  triggered  by  type  4  triggers,  i.e.,  allowable  limits 
triggered  requirements  for  allowable  limits  matching  forms 
subpart  data.  There  can  be  up  to  six  ID  18 s  if  the  base  line 
used  (or  chosen)  was  entered  on  different  forms  for  each  of 
the  up  to  6  data  elements  in  the  forms  subpart  for  which  the 
allowable  limit  evaluation  triggered  a  requirement.  There  may 
be  no  values  entered  in  this  field  if  the  allowable  limits 
did  not  involve  a  reference  to  base  line  data.  This  data 
comes  from  the  D518  data  corresponding  to  the  above  1022. 

14.  The  values  for  the  above  base  lines  entries.  There  can  be 
up  to  six  values.  From  the  DS 18  data  corresponding  to  the 


above  ID22. 
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15.  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
(ID14)  on  the  person  who  is  supposed  to  execute  the 
requirement.  This  data  comes  from  either  the  requirements 
appl icabil ity  data  (0S3,  DS4,  or  DS17  data),  for  requirements 
that  do  not  have  a  task  type  code  (CT8)  specified  for  them  in 
the  DS1  data  on  the  requirement  which  they  triggered;  or, 
from  the  specific  task  scheduling  data  (DS24)  for  the  task 
that  is  triggered  by  the  implementation  of  a  requirement  that 
is  covered  by  this  DS5  data.  The  DS24  data  may  not  contain 
such  an  I013/ID14  immediately  after  the  DS24  data  is 
generated,  because  the  OHMIS  program  was  unable  to  schedule 
the  task  triggered  by  this  requirement.  In  this  case,  a  code 
indicating  that  the  requirement  is  unscheduled  is  temporarily 
entered  here.  That  code  is  treated  like  an  OHMIS 
user/position  in  that  when  generating  the  outputs  telling 
user  of  an  outstanding  requirement  (i.e..  Outstanding 
Requirements  List  (04)  and  the  Requirement  Notification  and 
Certification  Record  (03),  this  requirement  is  listed  under 
the  "user/position"  "no  user/position  for  completing  this 
task  identified"  code.  This  remains  true  until  the  user 
supplies  the  information  needed  to  schedule  the  task  and 
identifies  the  person  who  is  suppose  to  execution  the  task. 

16.  The  current  employee  identifier  (ID4)  corresponding  to  the 
OHMIS  user/position  identifier  (1013  or  ID14)  from  above  for 
the  person  who  is  supposed  to  execute  the  requirement.  For 
DS5  data  for  requirements  without  a  task  type  code  (CT8) 
specified  in  the  DS1  data  corresponding  to  the  above  ID6,  the 
data  for  this  field  is  obtain  at  the  time  that  the  DS5  data 
is  generated  from  the  current  user/position  identity  and 
address  data  (DS9)  which  contains  the  employee  identifier  for 
the  person  currently  filling  each  OHMIS  user/position  office. 
For  requirements  with  a  task  specified,  the  104  for  this 
field  comes  from  the  specific  task  scheduling  data  (DS24). 

17.  The  same  as  above  for  the  management  person,  if  any,  who  is 
supposed  to  be  notified  of  the  requirement  in  order  to 
supervise  its  execution. 


18.  The  same  as  the  above  for  the  person,  if  any,  who  is 

supposed  to  approve  the  disposition  of  the  requirement. 


19.  Task  type  code  (CT8)  for  the  type  of  task  that  was 

triggered  by  this  set  of  requirements  implementation  data 
(DS5),  if  any.  From  the  requirement  description  data  (DS1) 
corresponding  to  the  above  requirement  identifier  (ID6),  if 
any,  task  type  code  (CT8)  was  specified  for  this  requirement. 


20.  Task  identifier  (1023)  for  the  task  that  was  triggered  by 
this  set  of  requirements  implementation  data  (DS5),  if  any 
was  triggered.  This  identifier  is  from  the  specific  task 
scheduling  data  (DS24)  generated  for  the  task  triggered  by 
this  0S5  data. 


Disposition  Data  Elements 


The  following  are  data  elements,  referred  to  as  "disposition  data 
elements,"  that  are  entered  by  the  user  using  Menu  Selection  Sequence 
1.5.3  (Function  F28).  These  data  elements  indicate  the  disposition  of 
the  requirement,  i.e.,  the  way  in  which  was  completed  or  executed.  The 
user  enters  this  data  by  manually  completing  the  bottom  portion  of  the 
Requirement  Notification  and  Certif ication  Record  (03)  or  Reminder 
Notice  List  (05);  these  completed  documents  are  then  used  to  enter  the 
requirements  disposition  data  onto  the  OHMIS  computer  data  base.  For 
Reminder  Notice  type  suspense  data  only  the  date  of  the  disposition  and 
the  type  of  disposition  (i.e.,  the  first  two  data  elements)  are  entered 
and  the  requirement  implementation  data  (DS5)  is  deleted  after  these 
entries.  That  is,  the  entry  of  these  two  data  elements  is  the  way  that 
the  user  tells  the  program  to  delete  the  DS5  data.  For  all  other  types 
of  DS5  data,  the  DS5  data  is  maintained  indefinitely  even  after  the 
requirements  disposition  information  has  been  entered.  The  entry  of 
complete  disposition  data  (i.e.,  including  requirements  approvals,  if 
needed)  also  results  in  the  deletion  of  the  specific  task  scheduling 
data  (D524)  for  the  task  that  was  scheduled  as  a  result  of  triggering 
the  requirement.  This  is  true  for  all  types  of  DS5  data.  The  DS24  data 
is  deleted  after  the  entry  of  all  disposition  data  onto  the  DS5  data 
set,  because  the  entering  of  disposition  data  on  a  requirement  is  the 
way  that  the  user  shows  that  the  task  associated  with  the  requirement 
(as  identified  by  the  task  type  code  (CT8)  on  the  requirement 
description  data  (DS1)  or  on  the  requirements  suspense  data  (DS4)  for 
tasks  triggered  by  Reminder  Notice  suspense  data)  has  been  completed  and 
that,  therefore,  the  task  should  be  deleted  so  that  is  does  not  remain 
on  the  monthly  schedule  data  (DS27). 

21.  The  date  that  the  disposition  of  the  requirement  was 
executed. 

22.  The  disposition  of  the  requirement.  Four  answers  are 
possible:  (1)  The  requirement  was  fully  completed;  (2)  The 
requirement  was  partially  completed;  (3)  The  requirement  was 
aborted,  i.e.,  the  user  decided  not  to  implement  the 
requirement  for  some  reason;  (4)  The  requirement  was  found  to 
be  not  applicable  for  some  reason. 

23.  A  description  of  what  part  of  the  requirement  was 
implemented,  if  the  disposition  was  "partially  completed". 

24.  A  description  of  the  rationale  for  the  disposition  of  the 
requirement,  if  the  requirement  was  not  fully  completed. 

25.  The  employee  identifier  (104)  of  the  person  who  executed 
the  disposition  of  the  requirement. 

26.  The  OHMIS  user  identifier  ( 1013)  or  OHMIS  position 
identifier  ( ID14)  for  the  person  who  executed  the 
disposition  of  the  requirement,  i.e.,  either  completed  it  or 
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determined  not  to  complete  it.  This  data  is  obtained  from 
the  current  user/position  identity  and  address  data  (DS9)  for 
the  employee  identifier  given  above.  This  identifier  should 
match  the  identifier  given  above  which  specified  the 
user/position  that  is  supposed  to  have  executed  the 
requirement;  if  it  does  not,  the  following  data  element  is 
requested:  the  explanation  for  why  a  person  other  than  the 
specified  person  above  executed  the  requirement.  If  no 
user/position  was  given  above  for  the  person  who  is  supposed 
to  execute  the  requirement,  then  this  data  element  does  not 
need  to  match  that  given  above  or  can  be  blank. 

27.  Date  that  the  disposition  of  the  requirement  was  approved. 

If  approvals  are  required,  the  requirement  is  not  considered 
to  have  been  executed  until  this  date  and  the  employee 
identifier  of  the  person  approving  the  disposition  is 
entered.  That  is,  information  on  the  approval  of  the 
disposition  of  the  requirement  may  be  entered  at  a  later  date 
than  information  of  the  disposition  of  the  requirement  and  it 
is  not  until  this  approval  information  is  entered  that  the 
requirement  is  removed  from  the  outstanding  requirements  list 
(DL3),  and  the  specific  task  scheduling  data  (DS24)  for  the 
task  involved  in  executing  this  requirement  is  deleted. 

28.  The  employee  identifier  (ID4),  if  any,  of  the  person  who 
approved  the  disposition  of  the  requirement. 

29.  The  OHM IS  user  identifier  (ID13)  or  OHMIS  position 
i dent i f i er  (1014)  of  the  person  that  approved  the 
disposition  of  the  requirement,  if  the  need  for  such 
approval  was  prescribed.  This  is  obtained  from  the  DS9  data 
associated  with  the  above  employee  identifier  (ID4).  This 
must  match  the  user/position  identifier  given  for  this 
approval  of  dispositions  in  the  same  way  as  that  explained 
for  the  match  for  the  person  who  executed  the  requirement. 

30.  Document  identifiers  (ID3)  or  completed  forms  identifiers 
( I D 1 8 )  for  the  document! s)  which  provide  additional 
information  about  the  disposition  of  the  requirement.  For 
example,  if  the  requirement  was  to  implement  a  preplacement 
physical  exam,  the  completed  forms  identifier  of  the  exam 
would  be  entered  here.  Up  to  five  identifiers  can  be  entered 
here. 
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Triggering  Step  Requirements  Implementation 
Unit  Identifier  Types  Data 

This  set  of  data  identifies  the  identifier  types  (or  data  element 
types)  that  are  the  requirements  implementation  units  for  a  given 
triggering  step.  Requirement  implementation  units  are  the  person  or 
thing  for  which  a  requirement  may  be  implemented.  For  example,  in  a 
requirenent  to  conduct  medical  surveillance  for  a  given  employee,  the 
identity  of  the  particular  employee  for  which  this  type  of  requirement 
is  being  implemented  would  be  the  requirement  implementation  unit  for 
that  implementation  of  the  requirement.  Similarly,  a  requirement  to 
conduct  an  Industrial  Hygiene  Survey  of  a  particular  facility  would 
have  the  identity  of  the  facility  as  the  requirement  implementation 
units  for  that  implementation  of  that  type  of  requirement. 

For  information  triggered  requirements  (i.e.,  those  based  on 
information  triggered  requirements  applicability  data  (DS3)),  the 
requirement  implementation  units  are  identified  during  the  execution 
of  the  triggering  step  as  entries  made  during  the  triggering  step. 
Because  a  particular  triggering  step  will  only  have  certain  specified 
data  elements  entered  during  the  step,  it  is  possible  to  identify  the 
types  of  data  elements  (most  of  which  will  be  identifiers  in  a 
triggering  step,  the  values  for  which  will  be  the  requirement 
implementation  units  entered  for  a  particular  execution  of  the 
triggering  step.  The  DS6  data  lists  these  identifier  types  or  data 
element  types.  This  data  is  thus  entered  by  the  OHMIS  system  designer 
at  the  time  that  the  triggering  step  is  programmed,  i.e.,  at  the  time 
that  a  particular  data  entry  step  in  the  OHMIS  computer  programs  is 
designated  as  a  triggering  step. 

There  can  be  up  to  five  identifier  types  (and/or  data  element  types) 
entered  during  a  triggering  step,  the  values  for  which  constitute  the 
requirement  implementation  units  for  a  particular  execution  of  the 
triggering  step.  A  triggering  step  may  have  additional  data  element 
types  entered  beyond  those  that  are  designated  as  requirement 
implementation  units. 

1.  Triggering  step  identifier  (ID2).  A  unique  value  that 
distinguishes  the  triggering  step  for  which  requirement 
implementation  unit  types  are  being  identified. 

2.  The  identifier  type  code  (CT10)  or  data  element  type  code 
(CT4)  for  requirement  implementation  unit  type  1,  2,  3,  4,  and 
5.  A  specific  unit  type  number  is  arbitrarily  assigned  to  each 
identifier  type  (or  data  element  type)  that  is  to  be  designated 
as  a  requirement  implementation  unit  for  the  triggering  step. 
This  enables  a  link  to  be  established  between  the  unit  type 
number  (1-5)  and  the  identifier  or  data  element  type  and  later 
the  values  for  the  identifier  type,  i.e.,  the  identifier  or  the 
values  for  the  data  element  type  that  are  entered  during  a 
particular  execution  of  the  triggering  step. 
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Data  Element  Type  Information 


This  set  of  data  provides  information  about  a  given  data  element,  i.e., 
about  an  individual  piece  of  information  contained  in  the  OHMIS  data 
base.  Examples  of  data  elements  include  date  of  birth,  sex,  a  test 
result  (e.g.,  for  a  medical  exam  or  an  Industrial  Hygiene  survey  sample 
test),  a  description  of  an  illness  or  medical  treatment,  a  dimension  of 
a  facility,  a  character istic  of  a  hazard,  etc.  The  name  or  code  number 
of  an  item  (e.g.,  of  a  disease  or  chemical)  is  not  a  data  element. 

Names  and  identifying  numbers  are  referred  to  as  identif iers  and  are 
treated  differently  than  data  elements. 

Data  Set  7  provides  information  about  one  particular  data  element  type. 
This  Data  Set  is  not  generated  by  the  user.  It  is  generated  by  an 
OHMIS  program  designer  (systems  programmer).  Users  may  request  new  data 
element  types,  but,  in  order  to  maintain  the  integrity  of  the  OHMIS  data 
base  (e.g.,  avoid  having  large  numbers  of  data  elements  that  are  not 
mutually  exclusive  or  distinctions  that  are  not  parallel),  a  new  data 
element  can  only  be  created  by  a  program  designer.  New  data  element 
types  are  added  centrally.  The  program  designer  assigns  a  data  element 
type  code  number  (CT4)  and  inputs  a  set  of  DS7  data  on  each  new  data 
element  type. 

A  given  data  element  type  will  have  one  meaning  and  will  be  used  in  the 
same  way  throughout  OHMIS,  i.e.,  in  all  OHMIS  Service  Areas.  An 
individual  Service  Area  may  request  that  a  new  data  element  type  be 
added,  if,  for  example,  a  special  piece  of  information  is  needed  in  the 
Service  Area.  However,  once  the  data  element  type  is  created,  it  will 
be  available  for  use  by  all  Service  Areas,  i.e.,  even  though  only  one 
Service  Area  may  use  the  data  element  type,  it  will  become  part  of  the 
central  "bank"  of  data  element  types  that  all  OHMIS  users  can  employ  and 
no  other  new  data  element  type  will  be  generated  that  conflicts  or 
overlaps  with  the  meaning  of  an  existing  data  element  type.  The  OHMIS 
Users'  Procedures  Manual  (as  described  in  Section  6.1)  will  provide 
guidelines  for  users  on  how  to  request  that  a  new  data  element  type  be 
added  to  OHMIS  and  for  program  designers  on  how  to  add  a  new  data 
element  type  by  generating  a  new  set  of  DS7  data. 

Once  a  set  of  DS7  data  has  been  generated  for  a  particular  piece  of 
information  (a  particular  data  element),  that  type  of  information 
becomes  one  of  the  types  of  information  that  can  be  entered  onto  the 
OHMIS  data  base.  The  particular  data  element  type  is  referred  to  by  the 
data  element  type  code  number  (CT4)  assigned  to  it.  As  a  designated 
OHMIS  data  element  type,  that  type  of  information  may  be  included  as  one 
of  the  data  element  types  on  an  OHMIS  form  designed  by  an  OHMIS  user. 
Thus,  while  an  OHMIS  user  shall  not  generate  a  new  data  element  type, 
the  individual  user  may  design  a  wide  variety  of  data  entry  sheets 
(referred  to  throughout  this  report  as  'OHMIS  forms')  using  a  combina¬ 
tion  of  existing  data  element  types.  (See  DS10,  OHMIS  Forms  Description 
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Data,  and  DS11,  Forms  Subpart  Data,  for  information  about  the  design  of 
new  OHMIS  'blank1  forms  by  OHMIS  users.)  The  data  elements  types 
described  in  DS7  data  thus  become  the  'building  blocks'  through  which 
OHMIS  users  design  OHMIS  forms,  tailoring  these  data  entry  sheets  to 
meet  their  individual  needs.  (Restrictions  on  the  number  and  types  of 
OHMIS  forms  that  may  be  developed  by  OHMIS  users  at  various 
organizational  levels  may  also  be  instituted  to  the  degree  desired.) 

DS7  data  is  added,  corrected  or  examined  through  Menu  Selection  Sequence 
5.  DS7  data  cannot  be  added,  deleted  or  changed  by  an  OHMIS  user. 

OHMIS  users  may  only  ex  amine  this  information.  OHMIS  program 
designers  may  add  or  correct  DS7  data.  It  is  anticipated,  however,  that 
changes  to  DS7  data  will  only  rarely  (if  ever)  be  made,  because  a  change 
would  require  a  complete  review  of  the  entire  OHMIS  data  base  to  make 
all  of  the  changes  needed  to  ensure  that  the  change  in  the  DS7  data  is 
incorporated  at  every  point  in  the  OHMIS  data  base  at  which  the  data 
element  type  is  used.  Instead,  in  most  cases  when  there  is  a  problem 
with  a  set  of  OS 7  data,  it  will  be  deactivated,  i.e.,  removed  from  the 
list  of  data  elements  that  users  may  employ  in  the  development  of  new 
OHMIS  forms  and  replaced  on  existing  OHMIS  'blank'  forms  (i.e,  DSIO  and 
0S11  data)  with  a  new  data  element  type  (i.e.,  one  with  a  new  data 
element  type  code  number)  that  does  not  have  the  problem.  The  OHMIS 
data  base  is  designed  so  that  a  change  on  an  existing  OHMIS  'blank'  form 
can  be  made  centrally  and,  in  most  cases,  will  be  transparent  to  the 
local  user. 

1.  Data  element  type  code  number  (CT4).  A  unique  code  number 
assigned  to  each  new  data  element  type  to  distinguish  it  from 
other  data  element  types. 

2.  Name  of  the  data  element  type.  The  short  description  of  the 
data  element  type. 

3.  Detailed  description  of  the  data  element  type.  This 
description  will  provide  sufficient  information  for  the  exact 
meaning  and  distinctions  about  the  data  element  type  to  be 
thoroughly  understood  by  the  reader. 

4.  Whether  this  data  element  type  has  been  deactivated. 

Answers:  Yes/No.  Deactivated  data  element  types  will  not 
appear  on  any  lists  generated  for  OHMIS  users  to  examine  data 
element  types.  (Only  program  designers  will  have  access  to 
these  sets  of  DS7  data.)  Also,  the  users  will  not  be  allowed 
to  use  deactivated  DS 7  data  sets  in  the  creation  of  new  forms 
subpart  data  (DS11)  done  as  a  part  of  designing  a  new  OHMIS 
form  (DSIO). 

5.  Identification  of  the  editing  subroutine  applicable  to  this 
data  element  type.  It  is  anticipated  that  there  will  be  a 
series  of  subroutines  that  provide  the  input  program  logic  for 
editing  data  onto  the  OHMIS  data  base.  These  program  will 
evaluate  a  data  entry  for  a  given  data  element  type  and 
determine  whether  the  input  is  an  acceptable  value.  It  is 
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expected  that  in  many  cases  the  same  editing  subroutine  can  be 
used  for  more  than  one  data  element  type,  because  the  program 
logic  for  conducting  the  editing  checks  will  be  the  same, 
even  though  the  exact  acceptable  values  may  or  may  not  be 
different  for  different  data  element  types.  For  example,  all 
data  element  types  that  have  acceptable  answers  of  'Yes/No/ 
Unknown/Not  Applicable'  can  be  edited  in  the  exact  same  way 
and  using  the  exact  same  acceptable  values.  Similarly,  all 
data  element  types  that  have  entries  that  are  numeric  and 
consist  of  a  defined  range  of  acceptable  values  (e.g.,  1-99, 
1-9,  1-4,  etc.)  can  be  edited  using  the  same  logic  but  will 
require  different  acceptable  values.  Because  of  this  similar¬ 
ity  in  the  editing  requirements  of  many  data  element  types, 
the  DS7  data  set  will  include  a  variable  indicating  to  which 
editing  subroutine  (if  any)  the  OHMIS  program  should  "Go  To", 
when  conducting  an  editing  check  on  the  entry  of  the  data 
element  described  by  the  DS7  data.  The  DS7  data  also  includes 
some  of  the  specific  characteristics  of  the  acceptable  values 
that  only  apply  to  the  particular  data  element  covered  by  the 
DS7  Data  Set.  (The  specifics  are  given  in  the  items  below.) 
The  inclusion  of  this  editing  information  on  the  DS7  Data  Set 
will  mean  that  in  many  instances  a  new  data  element  type  can 
be  added  without  any  additional  programming.  The  program 
designer  will  only  be  required  to  enter  a  new  set  of  DS7  data. 
Occasionally,  a  new  editing  subroutine  will  need  to  be  added 
to  edit  an  unusual  data  element. 

With  the  editing  information  provided  on  the  DS7  data,  the 
input  program  logic  will  work  as  follows:  The  data  element 
type  code  number  in  a  given  field  (e.g.,  on  an  OHMIS  form  or 
other  input  format)  indicates  what  data  element  type  is  to  be 
entered.  When  a  particular  value  for  a  data  element  is 
entered  (either  by  a  user  entering  data  from  an  OHMIS  form,  by 
entry  from  an  External  Data  Source  or  by  entry  using  a 
specially  designed  input  program),  the  program  will  use  the 
data  element  type  code  number  to  identify  the  DS7  data 
corresponding  to  the  type  of  data  element  to  which  the  value 
being  entered  belongs.  From  the  DS7  data  the  program  will 
determine  which  editing  subroutine  is  to  be  used  to  evaluate 
the  input  of  the  data.  Before  going  to  the  subroutine,  the 
program  will  capture  the  specific  editing  values  that  define 
the  acceptable  values  for  the  particular  data  element  (given 
in  the  items  below).  The  program  logic  will  then  go  to  the 
editing  subroutine  and  determine  if  the  input  "passes".  The 
program  logic  that  the  program  will  use  to  respond  to  a 
failure  to  pass  the  editing  requirements  will  depend  on  the 
type  of  input  program  being  used.  For  example,  an  interactive 
input  program  (such  as  the  input  of  data  from  an  OHMIS  form) 
would  probably  stop  at  each  input,  complete  the  editing  check 
and  request  re-entry  for  those  data  elements  which  fail  to 
pass  the  editing  requirements;  a  batch  processing  input 
program  (such  as  input  from  an  External  Data  Source)  will 
probably  conduct  the  editing  after  all  entries  of  a  given 
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kind  have  been  completed,  only  place  the  data  elements  that 
pass  the  editing  checks  into  a  permanent  storage  file  and 
generate  an  error  list  for  the  data  elements  that  failed  to 
pass. 

6.  Field  size  for  the  data  element  type  covered  in  this  DS7 
Data  Set. 

7.  Type  of  data  (alpha,  numeric,  alpha/numeric)  for  the  data 
element  type. 

8.  For  data  element  types  that  have  numeric  values: 

a.  Whether  or  not  the  value  is  a  number,  i.e.,  a  value  that 
can  be  manipulated  (e.g.,  added,  averaged,  etc.)  or  is  a 
code  number  (e.g.,  acceptable  values  are  1-4  which  are 
the  codes  for  the  words  'Yes/No/Unknown/Not  Applicable1) 
which  cannot  be  manipulated. 

b.  Whether  the  value  is  date.  The  editing  for  dates  is  so 
similar  that  it  is  efficient  to  identify  data  elements 
that  are  dates  and  treat  them  separately. 

c.  The  lowest  value  in  the  range  of  acceptable  values  for 
this  data  element  type. 

d.  The  highest  value  in  the  range  of  acceptable  value  for 
this  data  element  type. 

9.  For  alpha  or  alpha/numeric  values:  the  identification  of  the 
table  (if  any)  containing  the  acceptable  values  for  the  data 
element  type. 

10.  Up  to  6  identifier  type  codes  (CT10)  for  the  type  of  unit(s) 
which  is  described  by  this  data  element.  Most  data  elements 
will  describe  the  characteristics  of  a  person  or  thing.  For 
example,  'date  of  birth'  describes  the  age  of  a  person.  'Date 
of  construction'  describes  the  age  of  a  facility.  This  item 
in  DS7  identifies  what  type  of  unit  (e.g.,  an  employee,  a 
facility,  a  job  class,  a  hazard,  a  corrective  action,  a 
disease  or  illness,  etc.)  is  described  by  the  values  for  the 
data  element  type  described  in  this  set  of  DS7  data.  In  most 
cases  a  data  element  type  will  only  describe  one  unit  and  only 
one  unit  type  will  be  given  in  this  field  in  DS 7 .  However, 
some  data  element  types  describe  the  relationship  between  data 
elements.  For  example,  data  describing  an  exposure  to  a 
hazard  may  be  said  to  be  describing  the  characteristics  of  the 
relationship  between  an  employee,  a  hazard,  and  a  facility 
(three  types  of  units  constitute  the  units  described  by  an 
exposure  value).  A  thorough  study  has  revealed  that  such 
relationships  can  be  described  using  six  or  less  units.  This 
is  the  reason  that  DS7  allows  for  up  to  6  types  of  units  to  be 
identified.  The  information  about  the  unit  type  described 
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by  the  data  element  and  the  next  item  (below)  about  the  number 
of  values  of  the  data  element  type  for  a  given  unit  are 
important  for  storing  data  of  the  type  described  in  a 
particular  DS7  data  set. 

11.  Whether  or  not  there  can  be  more  than  one  value  for  this  data 
element  type  for  a  given  unit  described.  Answers :  Yes/No. 

For  example,  a  person  (i.e.,  a  given  unit)  can  only  have  one 
date  of  birth.  This  would  be  referred  to  as  a  'one-time  data 
entry',  because  there  can  only  be  one  valid  value  for  this 
data  element  type  for  any  given  unit  described  by  this  data 
element  type.  However,  a  person  may  have  more  than  one 
hearing  test  result.  Similarly,  although  a  person  has  only 
one  valid  value  for  his/her  weight  at  any  given  point  in  time, 
a  data  base  can  contain  more  than  one  value  for  a  person's 
weight  over  time,  because  values  change.  These  are  referred 
to  as  ‘multiple  entry'  data  elements. 

12.  The  location  in  which  a  value  for  the  data  element  type  is  to 
be  stored.  This  information  will  depend  on  the  files  and 
storage  configuration  selected  for  OHMIS.  However,  it  is 
anticipated  that  the  storage  will  be  keyed  to  the  type  of  unit 
described  by  the  data  element  type. 
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Values  Data  for  Requirement  Applicability  Characteristics 


This  data  describes  the  values  of  the  data  elements  describing  the 
characteristics  of  the  requirement  implementation  unit(s)  that  have  been 
determined  to  be  applicability  variables  for  a  particular  execution  of  a 
triggering  step  and  for  a  particular  potential  application  of  a 
requirement.  This  data  corresponds  to  the  requirements  applicability 
data  (DS3).  While  the  DS3  data  prescribes  the  types  of  data  elements 
and  values  that  constitute  on  set  of  applicability  variables  for  a 
requirement  (including  the  applicability  variables  for  the  requirement 
implementation  unit  itself  and  for  the  applicability  characteristics) , 
the  DS8  data  describes  an  actual  set  of  values  for  applicability 
characteristics  data  element  types  for  a  particular  execution  of  a 
triggering  step  and  for  a  particular  execution  of  a  requirements  check 
request.  That  is,  if  the  actual  values  in  the  DS8  data  match  the 
prescribed  values  given  for  a  particular  application  of  a  particular 
requirement  type  in  one  of  the  DS3  data  sets,  then  that  requirement 
referenced  in  the  DS3  data  is  considered  to  be  applicable  and  is 
implemented  through  the  generation  of  requirements  implementation  data 
(DS5).  For  example,  if  the  DS3  data  specified  that  a  particular 
employee  (where  the  employee  was  a  requirement  implementation  unit)  had 
to  be  a  certain  age  (the  applicability  characteristic  for  the 
requirement  implementation  unit)  for  a  particular  requirement  triggered 
by  a  given  triggering  step  to  be  considered  applicable,  the  DS8  data 
would  provide  the  age  of  that  particular  employee  at  the  time  that  the 
triggering  step  was  executed.  If  it  were  found  that  the  age  given  in 
the  DS8  data  matched  the  age  given  in  a  set  of  DS3  data,  the 
requirements  specified  in  the  DS3  data  would  be  found  applicable  and 
this  would  trigger  the  implementation  of  the  requirement. 

The  DS8  data  is  obtained  by  the  computer  program  for  those  data  elements 
which  the  OHMIS  data  base  already  contains  at  the  time  that  the 
triggering  step  initializing  the  need  to  determine  the  applicability  of 
requirements  is  executed.  If  all  of  the  data  is  available  on  the  OHMIS 
data  base  at  that  time,  the  computer  automatically  makes  the 
requirements  check  (i.e.,  determines  that  the  values  in  the  DS8  data  set 
matched  the  values  for  any  DS3  data  sets  for  the  same  triggering  step; 
if  so,  these  values  are  entered  on  the  requirements  implementation  data 
(DS5)  and  the  DS8  data  is  erased.  If  there  are  data  element  types  for 
which  the  values  are  not  currently  available  in  the  OHMIS  data  base  at 
the  time  that  the  triggering  step  is  executed  (i.e.,  the  OHMIS  program 
cannot  obtain  these  values  automatically),  these  data  element  types  are 
copied  onto  the  list  of  requirement  applicability  characteristics  for 
which  values  are  missing  (DL5);  this  list  is  used  to  tell  the  user  of 
the  missing  values  using  a  Requirements  Check  Notice  (01).  These 
missing  values  are  entered  onto  the  DS8  data  set  by  the  user  at  the  time 
that  the  requirements  check  (Menu  Selection  Sequence  1.2.3;  Function 
F2A)  is  executed.  At  that  time,  the  user  provides  the  values  for  the 
applicability  characteristics  that  were  missing  from  the  OHMIS  data  base 
at  the  time  that  the  triggering  step  was  executed. 
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1.  Requirements  check  request  identifier  ( 101 )  for  the  particular 
execution  of  the  triggering  step  that  prompted  the  search  to 
determine  whether  any  requirements  are  applicable.  Provided  by 
the  program.  This  is  the  same  value  that  is  on  the  requirements 
check  request  data  (DS2). 

2.  Requirement  application  identifier  (IDS)  for  the  particular 
potential  application  of  a  requirement  (i.e.,  the  set  of  DS3 
data)  for  which  this  DS8  data  provides  the  values  for  the 
applicability  characteristic  types  applicability  variables. 

This  data  is  provided  by  the  program. 

3.  The  requirement  identifier  (ID6)  given  on  the  requirement 
applicability  data  (DS3)  referenced  by  the  above  requirement 
application  identifier  (ID5). 

4.  Requirement  implementation  identifier  (ID9).  If  the  values  in 
this  0S8  data  set  match  the  values  prescribed  in  a  set  of 
information  triggered  requirements  applicability  data  ( DS3) ,  the 
requirement  will  be  triggered  and  monitored  for  implementation. 
This  will  be  done  by  generating  a  set  of  requirement 
implementation  data  (DS5).  If  DS5  data  is  generated  for  this 
requirement,  the  ID9  which  identifies  chat  requirement 
implementation  data  is  entered  here.  The  identification  of  the 
DS5  data  is  needed  during  the  requirements  check  before  the  DS8 
data  is  erased. 

5.  The  value  of  applicability  characteristic  type  1  for 
requirement  implementation  unit  type  1.  This  is  the  value  that 
the  data  element  type  specified  in  the  requirements 
applicability  data  (DS3)  for  the  above  referenced  requirement 
application  (105),  as  the  first  type  of  applicability 
characteristic  of  the  first  requirement  implementation  unit,  has 
for  this  particular  execution  of  the  triggering  step  in  which 
this  set  of  DS8  data  was  generated.  For  example,  if  the  first 
requirement  implementation  unit  was  an  employee  and  the 
requirement  applicability  data  specified  that  the  first 
applicability  characteristic  that  the  employee  must  have  for  the 
requirement  to  be  considered  applicable  was  to  be  a  certain  age, 
then  the  value  entered  here  would  have  the  age  of  the  particular 
employee  for  which  the  above  referenced  requirements  check 
request  was  generated,  i.e.,  the  age  of  the  employee  that  was 
the  requirement  implement  unit  for  this  execution  of  the 
triggering  step. 

6.  Values  of  applicability  characteristics  types  2-5  for 
requirement  implementation  type  1. 

7.  Values  of  applicability  characteristics  types  1-5  for 
requirement  implementation  units  types  2-5. 
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Current  User/Position  Identity  and  Address  Data 


This  data  identifies  the  current  person  who  is  acting  as  a  given  type  of 
OHMIS  user  or  filling  a  given  type  of  OHMIS  position  and  provides  the 
mailing  address  information  about  that  person.  Many  of  the  requirements 
data  sets  and  other  functions  of  OHMIS  depend  on  knowing  who  is 
'urrently  filling  a  given  OHMIS  user/position  office.  However,  it  is 
not  desirable  to  enter  the  identity  of  this  person  on  all  of  the  data 
sets  in  which  this  information  is  used,  because  this  would  mean  that 
many  data  sets  would  need  to  be  changed,  whenever  the  person  filling  the 
OHMIS  user/position  office  changed.  Instead,  whenever  possible,  users 
and  positions  are  referred  to  by  their  user  type  code  (Cli)  or  position 
type  code  (CT2)  or  by  their  OHMIS  user  identifier  (ID13)  or  OHMIS 
position  identifier  (ID14).  In  these  instances,  whenever  the  program 
reaches  a  function  requiring  knowledge  of  the  current  identity  of  the 
person  filling  the  OHMIS  user/position,  the  program  refers  to  the  DS9 
data  for  that  user/position  identifier  (ID13/ID14)  to  identify  the 
person  currently  filling  the  user/position.  (If  only  the  user/position 
type  code  (CT1/CT2)  is  known,  the  program  uses  the  OHMIS  user/position 
identifier  (ID13/ID14)  by  OHMIS  user/position  type  code  (CT1/CT2)  list, 
i.e.,  the  Dl8  list  and  the  OHMIS  user/position  identifier  (ID13/IDI4)  by 
OHMIS  service  area  (ID10)  list,  i.e.,  the  DL6  list,  to  first  identify 
the  ID13/ID14  and  then  refers  to  the  corresponding  DS9  data  to  identify 
the  employee  identifier  (ID4)  of  the  current  person  filling  the  OHMIS 
user/position. ) 

As  there  can  only  be  one  person  at  a  time  filling  a  given  OHMIS 
user/position  identifier  (ID13/ID14),  the  program  can  identify  the 
employee  identifier  (ID4)  for  the  one  current  person  corresponding  to  an 
ID13/ID14.  Only  the  current  DS9  data  is  maintained,  however,  and, 
therefore,  any  data  sets  that  require  maintaining  historical  data  on  the 
identity  of  the  persons  filling  a  given  OHMIS  user/position  (e.g.,  the 
requirements  implementation  data  ( DS5 ) )  must  store  the  employee 
identifier  as  well  as  the  OHMIS  user/position  identifier. 

DS9  data  is  similar  to  the  contact  and  location  data  (DS28)  in  that  both 
sets  of  data  provide  address  data.  However,  the  DS9  data  is  limited  to 
the  OHMIS  users  and  to  the  OHMIS  positions  that  play  an  active  role  in 
using  the  OHMIS  data  base  or  in  executing  occupational  health  program 
functions.  The  DS28  data  covers  contact  and  location  data  for  all  other 
employees  and  for  selected  things  (e.g.,  facilities). 

DS9  data  is  entered  by  the  user  using  Menu  Selection  Sequence  8.1.1.  As 
only  one  set  of  DS9  data  should  be  in  the  system  at  any  given  time  for 
any  given  OHMIS  user/position  identifier  (ID13/ID14),  the  DS9  entering 
program  should  check  for  already  existing  DS9  data  for  the  ID13/I014  on 
which  the  user  is  entering  DS9  data;  if  such  a  set  of  DS9  data  is  found, 
the  program  should  inform  the  user  and  ask  whether  the  user  is  entering 
a  replacement  value  for  the  existing  DS9  data  for  the  ID13/ID14  (in 
which  case  the  program  should  delete  the  existing  DS9  data  and  continue) 
or  whether  the  user  unintentional ly  entered  the  ID13/ID14  in  which  case 
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the  program  should  stop.  The  user  may  interchange  and  delete  the  DS9 
data. 

1.  OHMIS  service  area  identifier  (ID10  for  the  area  in  which 
this  set  of  0S9  data  applies. 

2.  OHM IS  user/position  identifier  (ID13/ID14)  for  which  this 
set  of  0S9  data  applies. 

3.  OHMIS  user/position  type  code  (CT1/CT2)  for  the  above 
1013/ 1014. 

4.  Employee  identifier  (ID4)  for  the  current  person  filling  the 
above  referenced  user/position  identifier  (ID13/ID14)  in  the 
above  referenced  Ol'MIS  service  area  (1010). 

5.  Work  address  data  for  the  above  employee  identifier.  This 
information  could  include  the  title  of  the  employee,  the 
mailing  address  and  phone.  The  mailing  address  can  be  the 
type  appropriate  for  mailing  internal  to  the  Department  of  the 
Army,  e.g.,  an  office  identifier  and  mail  stop  number. 
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Forms  Description  Data 


This  data  describes  the  contents  of  a  form,  i.e.,  the  data  element  types 
in  a  form.  The  data  element  types  are  defined  by  identifying  up  to 
twenty-five  sets  of  forms  subpart  data  (DS11).  Using  the  DS10  data  a 
separate  version  of  the  same  form  type  (CT9)  can  be  generated  for 
different  OHMIS  service  areas  (ID10)  and  for  different  applications  of 
the  form,  e.g.,  the  version  of  a  pre-employment  physical  type  of  form 
may  be  different  depending  on  the  job  class  to  which  the  employee  being 
hired  will  belong. 

The  DS10  data  is  entered  by  the  user  using  Menu  Selection  Sequence 
2.1.2.  The  0S10  data  prescribes  a  record  length  and  composition  for  all 
data  entry  forms  used  in  OHMIS.  Therefore,  in  order  to  maintain  the 
integrity  of  the  data  base,  historical  DS10  data  is  maintained.  DS10 
data  cannot  be  changed  (except  for  the  narrative  portions  such  as 
instructions  and  subtitles)  and  is  not  deleted,  although  it  can  be 
deactivated,  i.e.,  an  indication  that  this  version  of  the  form  is  no 
longer  to  be  used  can  be  made  by  supplying  an  end  date  for  the  data  set. 

1.  Forms  specif ication  identifier  (ID16).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS10  data. 

2.  Form  type  code  (CT9)  indicating  what  type  of  form  this  is 
(e.g.,  medical  history,  hazard  survey,  etc.). 

3.  OHMIS  service  area  identifier  (ID10)  for  the  service  area 
specifying  this  version  of  this  form  type. 

4.  OHMIS  user  identifier  (ID13)  of  the  person  specifying  this 
version  of  the  form. 

5.  Employee  identifier  (ID4)  of  the  person  specifying  this 
version  of  the  form. 

6.  Start  date  for  this  version  of  the  form,  i.e.,  the  date 
that  this  version  of  the  form  was  specified  or  the  date  that 
it  can  first  be  used. 

7.  End  date  for  using  this  version  of  the  form  (deactivation 
date).  Can  be  blank  if  the  form  is  still  active. 

8.  Is  this  a  "default"  version  of  this  type  of  form  for  this 
OHMIS  service  area?  Answers:  Yes/No.  Using  the  prescribed 
forms  applicability  values  data  (DS13),  the  user  will 
indicate  the  applications  of  this  version  of  the  form  type, 
e.g.,  in  the  above  example  the  user  would  indicate  for  what 
job  classes  this  version  of  the  form  is  to  be  used.  In  order 
that  the  applications  data  not  have  to  be  comprehensive, 
there  will  be  a  default  version  of  each  type  of  form  (CT9) 
for  each  OHMIS  service  area  (1010)  which  will  be  used  if 


there  is  not  other  form  that  meets  the  applicability  values 
for  the  form  type  and  OHMIS  service  area.  The  user  may  elect 
to  use  this  version  of  the  form  at  any  time. 


For  any  point  in  time  there  can  only  be  one  active  default 
version  of  a  particular  form  type  (CT9)  for  a  part.cular 
OHMIS  service  area  (IDIO).  If  the  user  answers  this  question 
"Yes",  the  entry  program  will  check  that  there  is  currently 
no  other  active  default  version  of  this  form  type  for  this 
OHMIS  service  area  before  preceding.  If  there  is,  the 
program  will  tell  the  user  and  ask  the  user  if  the  user 
wishes  to  change  his  answer  (i.e.,  not  call  this  set  of  DS10 
data  the  "default"  version)  or  to  deactivate  the  existing 
default  version.  If  the  later,  the  program  will  supply  the 
current  date  as  the  deactivation  date  for  the  existing  (old) 
default  version;  remove  the  forms  specification  identifier 
(1016)  for  the  old  default  version  from  the  list  of  the 
active  default  forms  specification  identifier  by  form  type 
code  and  OHMIS  service  area  (DL21);  continue  to  generate  the 
new  DS10  data  as  default  data;  and  add  the  above  identified 
forms  specification  identifier  (1016)  for  the  new  DS10 
default  version  to  the  0L21  list. 

Supplemental  title  of  form.  The  vocabulary  word/phrase 
associated  with  the  form  type  code  (CT9)  given  above  is  part 
of  the  title  of  the  form;  however,  the  data  element  listed 
here  provides  any  additional  subtitles  identifying  this 
version  of  the  form. 

General  instruction  for  using  the  form.  This  is  narrative 
data. 

The  identifier  type(s)  (CT10)  (or  data  element  type  ( CT4) ) 
for  the  up  to  nine  types  of  identifiers  for  which  the  data  on 
this  form  will  prescribe  characteristics;  these  are  referred 
to  as  forms  units.  Such  identifier  types  include  employee 
identifiers,  facility  identifiers,  hazard  identifiers,  job 
Class  identifiers,  etc.  (see  the  identifier  (ID)  list  for 
most  of  the  types  of  identifiers  that  will  be  used  in  OHMIS.) 
This  data  indicates  the  type  of  unit  that  is  to  be  described 
in  the  data  given  on  this  form.  For  example,  a  form  that  is 
a  medical  exam  would  have  an  employee  as  the  type  of  forms 
unit  (type  of  identifier)  being  described  in  the  data  on  that 
form.  A  form  for  conduction  a  hazard  survey  of  a  facility 
would  have  "facilities"  as  the  type  of  forms  unit.  Data 
about  the  characteristics  of  a  particular  type  of  hazard 
(e.g.,  material  safety  data  sheet  type  of  data)  would  have 
the  hazard  type  as  the  type  of  identifier  being  described, 
etc.  Some  forms  will  have  multiple  types  of  forms  units. 

This  can  be  either  because  the  different  forms  subparts  on  a 
single  form  refer  to  (i.e.,  provide  data  on  the 
characteristics  of)  different  types  of  units;  and/or,  because 
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some  of  the  individual  forms  subparts  refer  to  (i.e.,  provide 
data  about)  combinations  of  units.  For  example, 
hazards  data  often  describes  the  characteristics  of  a 
combination  of  a  hazard,  an  individual  employee  and  a 
facility;  some  corrective  actions  data  (such  as  personal 
protective  equipment)  may  describe  the  characteristics  of  an 
individual  employee  and  a  hazard,  etc.  For  these  reasons,  up 
to  nine  types  of  identifiers  can  be  given  as  forms  units  on 
an  OHM IS  form. 


It  is  essential  that  the  identifier  types  given  here  are 
correct  for  (consistent  with)  the  data  element  types  in  the 
forms  subpart  data  (DS11)  specified  below.  Each  of  the  forms 
subparts  may  have  a  forms  unit  which  that  individual  forms 
subpart  describes.  The  type  of  unit  or  combination  of  units 
are  given  in  the  0S11  data  for  the  forms  subpart.  It  is 
essential  that  the  forms  unit  for  a  given  forms  specification 
(DS10  data)  include  all  of  the  forms  units  for  all  of  the 
forms  subparts  included  on  the  form,  (in  many  cases  more 
than  one  form  subpart  on  a  form  will  refer  to  the  same  forms 
unit  as  being  the  unit  that  the  forms  subpart  data  is 
describing.)  The  program  checks  for  this  internal 
consistency  requirement  when  the  forms  unit  types  are 
entered. 


Not  only  are  there  forms  units  for  most  of  the  forms  subparts 
included  on  a  form,  there  may  be  forms  units  for  the  form 
specification  as  a  whole.  These  are  used  when  specifying 
allowable  limits  for  the  form-as-a-whole  (as  explained 
below).  The  link  showing  which  forms  units  refer  to  which 
forms  subparts  is  given  below.  The  link  showing  which  forms 
units  refer  to  the  form  as  a  whole  is  given  here  in  the  form 
of  a  Yes/No  answer  next  to  each  forms  unit.  Just  as  each 
type  of  form s  unit  may  refer  to  more  than  one  forms  subpart, 
so  a  type  of  forms  unit  may  refer  to  both  the  form  as  a  whole 
and  a  form  subpart. 


The  conventional  use  of  allowable  limits  specifies  limits  for 
specific  data  element  types  such  as  a  limit  for  a  particular 
type  of  test  or  sampling  result.  These  types  of  allowable 
limits  are  given  in  OHMIS.  In  addition,  however,  OHMIS 
allows  the  specif ication  of  an  "allowable  limit"  on 
forms-as-a-whole.  It  should  be  recognized  that  in  OHMIS  an 
allowable  limit  > or  unallowaole  limit)  is  specified  when  an 
action  or  requirement  should  be  triggered  if  the  limit  is 
reached  or  matched.  In  some  coses  requirements  should  be 
triggered  by  the  mere  fact  of  entering  a  certain  class  of 
data  (or  entering  that  class  of  data  at  a  certain  frequency). 
For  example,  a  user  may  wish  to  trigger  a  requirement 
whenever  data  on  a  hazardous  substance  spill  is  entered  or  if 
such  data  is  entered  more  than  'X'  times  in  a  given  time  span 
for  a  given  facility.  In  these  instances  the  allowable  limit 
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does  not  apply  to  any  individual  data  element  entered,  but  to 
the  mere  fact  of  entering  data  of  a  certain  class.  For 
allowable  limits  of  this  type,  the  user  specifies  limits  for 
the  class  of  data,  where  the  class  of  data  is  identified 
by  the  type  of  form  (CT9)  (not  the  version  of  the  form). 

In  the  above  example,  each  time  data  for  a  report  of  a 
hazardous  substance  spill  type  of  form  (the  type  of  form  to 
be  used  to  report  spills  and  other  events/accidents  involving 
hazardous  substances)  was  entered  (regardless  of  the  values 
entered  on  the  form),  the  program  will  check  for  allowable 
limits  for  this  class  of  data. 

As  with  the  more  conventional  allowable  limits,  there  may  be 
applicability  factors  (some  of  which  are  forms  units)  aM 
values  which  determine  which  allowable  limits  are  to  be  used. 
There  will  also  be  a  type  of  forms  unit  (or  combination  of 
forms  unit  types)  to  which  the  class  of  data  refers  and  which 
is  used  to  define  the  allowable  limit.  In  the  above  example, 
the  user  may  wish  to  specify  that  there  can  be  no  more  than 
'X'  reports  of  hazardous  substance  spills  entered  onto  the 
OHMIS  data  base  for  a  given  organizational  unit  or  for  a 
given  faci 1 ity.  In  these  examples  the  organizational 
unit  and/or  facil ity  becomes  the  forms  unit  for  the 
form-as-a-whole  ( i . e . ,  for  the  class  of  data  that  is  defined 
by  the  form  type  (CT9)  ).  The  user  can  then  specify 
allowable  limit  applicability  characteristics  (on  the  DS15 
and  DS16  data)  about  these  forms  units,  e.g.,that  the  number 
of  persons  working  in  the  facility  determines  which  allowable 
limit  is  to  be  used  for  this  class  of  data.  The  forms  units 
are  then  also  used  to  define  the  allowable  limit,  e.g.,  the 
allowable  limit  in  the  above  example  becomes:  "'X1  number  of 
hazardous  substance  spill  reports  is  entered  for  a  single 
faci 1 i ty  (forms  unit)  having  the  allowable  limit 
applicability  characteristics  specified  for  this  data". 

In  this  OSLO  data  element  the  user  identifies  these  forms 
unit(s)  for  the  form-as-a-whole  using  the  number  of  the  order 
in  which  the  form  unit  appears  on  this  specification  of  tv- 
form,  i.e.,  numbers  from  1  to  9.  There  can  be  no  more  than  6 
forms  units  identified  as  the  combination  of  units  that  apply 
to  a  form-as-a-whole;  in  most  cases,  there  will  probably  be 
only  one. 

It  should  be  noted  that  for  both  forms  subparts  and 
forms-as-a-who)e,  the  types  of  forms  units  used  to  define 
the  allowable  limit  must  be  one  of  the  data  element  types 
( C T 4 )  or  identifier  types  (CT10)  entered  on  the  form,  i.e., 
included  in  the  guestions  asked  on  the  data  entry  form  and 
entered  as  a  part  of  the  completed  forms  data  (DS14).  In  the 
above  example,  if  the  allowable  limit  is  defined  as  "'K' 
numbers  of  hazardous  substance  spill  reports  for  a  single 
faci 1 ity"  then  the  identity  of  the  facility  must  be 
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entered  on  the  form  as  a  forms  unit.  Similarly,  for  a  more 
conventional  allowable  limit,  if  the  allowable  limit  is 
defined  as  "X  number  of  millirems  of  radiation  exposure  for 
a  single  employee"  the  identity  of  the  employee  must  be  on 
the  form  used  to  enter  the  data  on  exposure  as  a  forms  unit. 

On  the  other  hand,  the  allowable  limit  applicability 
characteristics  of  these  forms  units  (such  as  stating  that 
the  population  in  the  facility  determines  which  allowable 
limit  will  be  used  for  the  number  of  reports  of  hazardous 
substance  incidents  that  can  oe  entered  without  triggering 
the  requirement  associated  with  the  allowable  limit  or  that 
the  sex  of  the  employee  determines  which  millirem  of  exposure 
limit  will  be  used  for  the  allowable  limit)  do  not  have  to 
be  entered  each  time  the  form  is  completed;  the  OHMIS 
program  can  abstract  the  values  for  these  appl icabi 1 i ty 
characteristics  specified  in  the  al lowable  limits 
applicability  data  (DS15  and  DS16)  for  the  forms  unit  entered 
onto  the  form. 

12.  Up  to  25  sets  of  the  following  three  data  element  types. 

These  sets  of  three  data  element  types  indicate  the  contents 
of  the  form,  i.e.,  the  data  element  types  (questions)  that 
are  to  be  asked  for  on  the  form.  The  number  in  the  sequence 
of  sets  (i.e.,  the  number  1  through  25)  is  maintained  in  the 
data  base  so  that  the  order  in  which  the  data  elements 
(questions)  are  to  be  printed  onto  the  form  is  captured.  (If 
the  user  wishes  to  specify  a  form  with  the  same  data  elements 
but  in  a  different  order,  this  would  be  done  on  a  different 
set  of  DS10  data  with  another  forms  specification  identifier 
(1015).) 

a.  The  forms  subpart  identifier  (ID17).  This  identifies 
a  series  of  up  to  six  data  elements  (with  any 
subtitles,  instructions  and  the  actual  wording  of  the 
question  on  the  form)  that  are  given  on  the  form 
subpart  data  (DS11). 

b.  The  number  of  sets  of  the  DS11  data  identified  above 
for  which  data  entry  spaces  are  to  be  provided. 

Answer:  from  1  to  99.  Answers  of  greater  than  1  are 
given  in  this  field  when  the  form  being  described  in 
this  DS10  data  set  is  to  provide  data  entries  for  a 
series  of  data  elements  all  of  the  same  type,  i.e.,  all 
with  the  same  form  subpart  identifier  (1017).  For 
example,  if  the  form  being  designed  by  this  set  of  0S10 
data  was  to  be  used  to  list  the  identifiers  for  the 
employees  attending  a  training  session,  the  user  would 
list  in  the  field  above  the  forms  subpart  identifier 
(1017)  corresponding  to  the  data  entry  of  employee 
identifiers  and  in  this  field  would  reference  the 
number  of  sets  of  employee  identifier  data  (i.e.,  the 


DATA  SET  10 


number  of  sets  of  forms  subpart  data)  the  user  expects 
to  use  to  enter  all  employee  identifiers  on  any  given 
use  of  this  form.  Another  example  would  be  a  form 
designed  to  record  exposure  data  for  a  series  of 
hazards.  The  user  would  select  in  the  field  above  the 
forms  subpart  identifier  (1017)  for  the  forms  subpart 
containing  the  data  elements  needed  to  enter  exposure 
data  on  hazards.  Then  in  this  field  the  user  would 
enter  the  number  of  sets  of  this  form  subpart  data 
needed  to  enter  the  expected  number  of  hazards  that 
would  be  described  on  any  one  form. 

The  information  identifying  the  form  unit(s)  for  the 
above  referenced  forms  subpart,  i.e.,  the  information 
identifying  which  identifier  type(s)  or  data  element 
type(s)  this  form  subpart  will  be  describing  by 
providing  space  for  information  on  the  form  being 
prescribed  in  this  DS10  data  set.  This  information  can 
be  given  in  one  or  both  of  the  following  two  ways:  1) 

A  number(s)  from  0  to  9  indicating  which  of  the  above 
referenced  forms  unit  identifier  types  the  data 
element  types  in  the  above  referenced  forms  subpart  are 
describing.  The  value  '0‘  would  be  added  if  the  forms 
subpart  does  not  describe  any  type  of  identifier. 

(This  would  have  been  indicated  on  the  forms  subpart 
data  (DS11)).  However,  if  the  data  provided  in  the 
forms  subpart  is  to  be  evaluated  for  allowable  limits 
(see  Function  F3B),  the  type  for  form  unit  identifier 
described  by  the  data  in  this  form  subpart  must  be 
identified.  (2)  A  number  from  1  to  6  indicating 
which,  if  any,  of  the  up  to  six  data  element  types  in 
the  forms  subpart  referenced  above  is  to  be  treated  as 
the  forms  unit  for  this  subpart. 

The  ability  to  identify  forms  units  in  these  two  ways 
is  provided  for  in  order  to  give  the  user  greater 
flexibility  in  designing  forms.  For  example,  a  form 
cons  sing  of  information  about  an  employee  (such  as  a 
pre-employment  physical)  would  probably  have  the  forms 
unit  for  most  or  all  of  the  forms  subparts  on  the  form 
as  an  employee  identifier  and  this  would  be  entered 
once  (at  the  top  of  the  form)  as  one  of  the  up  to  9 
form  units  identifiers  that  apply  to  the  entire  form. 
This  would  be  using  method  (1)  for  identifying  forms 
units  for  a  forms  subpart.  However,  for  a  form  that 
was  organized  to  allow  input  of  exposure  data  for 
several  different  hazards  or  large  numbers  of  hazards 
it  may  not  be  convenient  to  have  the  form  units  (i.e., 
the  identifiers  for  the  several  different  hazards) 
listed  as  forms  units  at  the  top  of  the  form  and 
covering  the  entire  form,  especially  as  only  9  such 
forms  units  could  be  used,  i.e.,  only  9  different 
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hazards  could  be  described  on  a  single  form.  Instead 
the  user  may  wish  to  organize  the  form  so  that  the 
hazard  identifier  (i.e.,  the  forms  unit)  is  the  first 
data  element  type  in  the  forms  subpart  data  itself 
and  this  is  followed  by  the  hazard  exposure  data  as  a 
part  of  the  same  form  subpart.  In  this  case  the  user 
would  be  using  method  (2)  for  identifying  the  forms 
units  for  a  forms  subpart.  This  method  would  enable 
the  user  to  enter  as  many  as  2475  sets  of  hazard 
exposure  data  each  for  a  different  hazard  and  each 
having  a  different  forms  unit,  (there  can  be  up  to 
2475  form  subparts  on  a  single  form  by  prescribing  a 
form  with  the  full  25  different  subparts  and  the  full 
99  sets  of  the  same  form  subpart  for  each  of  these  25 
subparts;  this  type  of  organization  of  a  forms  design 
would  obviously  only  be  used  for  a  form  that  was 
primarily  used  to  list  large  numbers  of  the  same  type 
of  information,  e.g.,  a  list  of  all  hazards  found  in  a 
facility  or  a  list  of  all  employees  in  a  facility.) 

To  enter  this  forms  unit  information  for  a  form 
subpart,  the  user  must  first  indicate  what  method  is 
being  used  (method  (1)  or  (2))  and  then  what  the  value 
for  the  forms  unit  is,  i.e.,  0  to  9  for  forms  unit 
identified  at  the  top  of  the  form  and  1  to  6  for  forms 
units  that  are  a  data  element  type  in  the  form  subpart. 
Up  to  a  total  of  six  forms  units  may  be  identified  for 
each  forms  subpart,  although  in  most  cases  there  will 
be  only  one  forms  unit.  The  reason  why  there  may  be 
more  that  one  forms  unit  being  described  by  a  set  of 
forms  subpart  data  is  that  some  types  of  data  describe 
a  relationship  between  identifiers.  For  example, 
exposure  data  could  be  said  to  describe  the 
relationship  between  an  employee,  a  hazard,  and  a 
facility;  in  this  case  there  would  be  3  forms  units, 
i.e.,  3  identifiers  for  which  the  hazard  exposure  data 
was  describing  characteristics .  The  up  to  6  forms 
units  for  a  given  forms  subpart  that  identify  the  item 
or  items  that  the  forms  subpart  is  describing  can  be 
identified  using  one  or  both  of  two  methods  for 
identifying  forms  units  for  a  form  subpart. 

The  types  of  forms  unit  identi  rs  specified  in  this 
field  as  being  the  type  of  unit  which  the  data  in  the 
forms  subpart  is  describing  must  be  consistent  with  the 
type  of  forms  unit  identifiers  given  in  the  forms 
subpart  data  (DS11)  for  the  respected  forms  subpart 
identifier  (IDI7).  If  not,  the  DS10  entry  program  will 
require  that  either  a  value  of  'O'  be  used  (meaning  no 
allowable  limits  will  be  checked  for  this  forms  subpart 
data  because  no  forms  units  have  been  identified,  i.e., 
no  unit  about  which  an  allowable  limit  could  be  set  has 
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been  identified)  or  it  will  require  that  additions  be 
made  to  the  types  of  forms  unit  identifiers  given  on 
the  DS10  data  so  that  it  is  possible  to  reference  a 
forms  unit  that  is  the  appropriate  type  of  identifier 
for  the  forms  subpart  data  being  entered. 

The  values  entered  in  this  field  (up  to  6  values 
ranging  from  either  '0'  to  '9'  or  from  'O'  to  '6') 
indicates  the  location  (field)  that  will  contain  the 
particular  forms  unit  identifier  being  described  by 
this  forms  subpart  data.  These  values  link  the  forms 
subpart  data  to  the  particular  order  in  which  the  forms 
unit  identifier  data  corresponding  to  the  DS11  data  (on 
the  acceptable  types  of  forms  unit)  is  given.  That 
is,  this  information  indicates  the  location  (field) 
that  will  contain  the  particular  forms  unit  identifier 
being  described  by  this  forms  subpart  data  on  the  new 
version  of  the  form  being  described  by  this  set  of  DS10 
data.  It  should  be  recognized  that  in  many,  perhaps 
most,  instances  there  will  only  be  one  forms  unit 
identifier  (unit  being  described  on  a  form)  for  a  given 
version  of  a  form.  In  those  instances  the 
identification  of  forms  units  for  the  various  forms 
subparts  that  make  up  a  description  of  a  version  of  a 
form  will  be  identified  very  easily  as  they  will  be  the 
same  for  all  of  the  form  subparts  that  make  up  the 
form. 

In  addition  to  the  subpart  specified  above,  all  OHMIS  data 
entry  forms  will  have  spaces  for  a  series  of  identification 
data  elements  at  the  top,  e.g.,  the  identity  of  the  person 
completing  the  form,  the  date  that  the  form  was  completed, 
etc.  These  data  elements  are  similar  for  almost  all  forms 
and  are  therefore  shown  in  the  generic  description  of  an 
OHMIS  form  given  in  the  completed  forms  data  (DS14) 
description. 

13.  OHMIS  user  type  (CT1)  or  position  type  (CT2)  of  the  type  of 
person  who  is  supposed  to  complete  this  form,  if  any  is 
specified. 

14.  Whether  or  not  this  form  is  to  be  reviewed  by  anyone. 

Answer:  Yes/No. 

15.  OHMIS  user  type  (CT1)  or  position  type  (CT2)  of  the  type  of 
person  who  is  to  review  ('sign  off  on')  this  form,  if  any  is 
specified. 

16.  Length  of  time  from  the  date  that  the  blank  form  is 
generated  to  the  date  that  the  completed  form  is  due.  May  be 
left  blank,  if  unspecified. 
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17.  Length  of  time  for  which  the  hard  copy  of  the  forms  of  this 
specification  are  to  be  maintained.  The  value  in  this  field 
may  be  zero. 

18.  Whether  or  not  this  is  a  one  time  form,  that  is  a  form  that 
will  be  filled  out  once  for  a  given  form  unit(s).  This  could 
be  true  because  of  the  nature  of  the  form  or  because  each  of 
the  forms  subparts  on  the  form  contain  only  data  element 
types  that  are  non  changing  data  element  types.  The  answer 
given  in  this  field  is  to  designate  the  form  as  a  'one  time 
form'  or  a  ‘multiple  use'  form.  One  time  forms  are  forms 
that  contain  data  that  does  not  change  and  for  which  there 
cannot  be  multiple  values.  For  example,  a  persons  date  of 
birth  is  a  one  time  data  element  and  a  form  containing  only 
data  elements  of  this  type  would  be  a  one  time  form.  The 
reason  why  a  one  time  form  needs  to  be  identified  is  that  the 
allowable  limits  evaluation  for  a  one  time  form  will  be 
conducted  differently  than  it  will  be  for  a  multiple  use  form 
because  it  will  not  be  necessary  to  compare  current  entries 
with  previous  entries  to  determine  whether  an  allowable  limit 
has  been  reached.  An  example  of  a  multiple  use  form  would  be 
a  hearing  test  form;  it  is  expected  that  this  type  of  form 
would  be  filled  out  multiple  times  for  the  same  employee 
(i.e.,  for  the  same  forms  unit). 

19.  Whether  or  not  any  of  the  forms  subparts  included  in  this 
version  of  the  form  contain  data  element  types  of  the  type 
that  could  have  base  line  information,  i.e.,  entry  level 
(pre-exposure  level)  measures  the  comparison  to  which  is  used 
to  measure  changes  in  or  affects  of  exposures  as  an  employee 
of  the  Department  of  the  Army.  Such  a  form  would  be 
identified  as  a  'no  base  line  form’  or  as  a  ’base  line  form1. 
If  the  form  was  designated  above  as  a  one  time  form,  then 
the  form  is  necessarily  a  no  base  line  form.  A  hearing  test 
is  an  example  of  a  data  element  type  that  is  likely  to  have 
base  line  information  on  it,  i.e.,  information  about  the 
persons  hearing  before  exposure  while  employed  with  the 
Department  of  the  Army.  If  the  form  contains  any  such  data 
element  types  it  would  be  classified  as  a  base  line  form  type 
of  form. 
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Forms  Subpart  Data 


This  data  identifies  a  particular  set  of  up  to  six  data  elements  that 
may  be  used  in  the  composition  of  an  OHMIS  form.  In  addition  to 
providing  the  data  element  types  (CT4)  that  will  go  on  a  form,  this  data 
set  provides  the  subinstruction,  subtitles,  and  exact  wording  of 
questions  that  will  be  used  on  an  QriMIS  form.  The  DS11  data  is  used  in 
the  forms  specification  data  (DS10)  to  describe  the  contents  of  a  form. 
DS11  data  is  entered  by  the  user  using  Menu  Selection  Sequence  2.2.2. 

The  same  sets  of  DS11  data,  once  specified,  are  used  throughout  OHMIS. 
Users  from  different  OHMIS  service  areas  refer  to  these  "standard"  sets 
of  data  elements  to  specify  the  contents  of  a  particular  form  for  use  by 
their  respected  service  area.  The  same  form  subpart  may  be  used  in  more 
than  one  form.  The  DS11  data  entry  program  (Menu  Selection  Sequence 
2.2.2)  thus  checks  to  determine  if  there  are  duplicate  DS11  sets  of  data 
already  entered  on  the  OHMIS  data  base.  The  data  element  types  used  by 
a  user  to  specify  a  particular  form  subpart  are  defined  and  controlled 
by  the  OHMIS  program  designer  (i.e.,  the  software  staff)  not  the  user. 
The  DS11  data  set  merely  allows  the  user  to  group  together  existing 
data  element  types  developed  by  the  OHMIS  system,  not  created  new  data 
element  types. 

In  order  to  preserve  the  integrity  of  the  OHMIS  data  base,  DSll  data 
cannot  be  changed  (except  for  narrative  portions  such  as  instructions) 
or  deleted.  This  data  is  not  dated,  i.e.,  there  are  no  beginning  and 
end  dates  for  this  data,  because  generically  speaking  this  type  of  data 
acts  as  a  dictionary  (thesaurus  or  vocabulary  set)  from  which  forms  are 
composed . 

Some  care  needs  to  be  exercised  in  selecting  data  element  types  to  be 
grouped  together  in  a  given  forms  subpart.  For  one  thing  all  of  the 
data  elements  in  a  given  set  of  forms  subpart  data  must  reasonably  be 
said  to  describe  the  same  type  of  unit  (or  group  of  types  of  units), 
i.e.,  the  same  forms  units  (see  below).  Also  the  up  to  6  data  element 
types  in  a  forms  subpart  are  treated  as  a  group  in  evaluating  allowable 
limits  (See  allowable  limits  specification  data  (DS17)  and  Function 
F3B.)  This  has  its  advantage  in  that  allowable  limits  can  be  specified 
in  terms  of  relationships  between  the  up  to  6  data  elements  in  a  given 
forms  subpart.  However,  should  the  user  wish  some  data  elements  treated 
separately  with  regard  to  allowable  limits,  it  would  be  necessary  to 
generate  additional  sets  of  DSll  data  (with  each  of  the  individual  or 
groups  of  data  element  types  that  are  to  be  treated  separately  on  a 
separate  DSll  data  set)  and  to  use  the  forms  subpart  identifiers  (ID17) 
for  these  forms  subpart  data  sets  when  specifying  the  contents  of  a 
form. 

1.  Forms  subpart  identifier  (ID17).  Unique  value  assigned  by 
the  program  to  distinguish  this  set  of  DSll  data. 
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2.  Subtitle,  if  any,  that  goes  with  this  set  of  data  elements 
(i.e.)  this  forms  subpart  data  set)  when  it  is  printed  on  a 
form.  (The  DS10  data  will  provide  the  overall  title  for  the 
form. ) 

3.  Instructions,  if  any,  that  go  with  this  set  of  DS11  data 

when  it  is  printed  on  a  form.  (The  DS10  data  will  provide  the 
general  instructions  for  the  entire  form). 

4.  From  0  to  6  identifier  type  codes  (CT10)  or  data  element  type 
codes  (CT4)  identifying  the  types  of  units  described  by  the 
data  in  this  forms  subpart.  These  are  referred  to  throughout 
all  data  sets  as  forms  units.  For  example,  data  about  an 
employee's  age  and  sex  on  a  form  would  have  an  employee  as  the 
type  of  form  unit  being  described.  Data  on  the  size  of  a 
building  would  have  a  facility  as  the  type  of  forms  unit. 

This  field  can  be  left  blank  if  there  are  no  types  of  units 
being  described.  More  that  one  type  of  unit  may  be  described, 
especially  for  those  data  element  types  that  describe 
characteristics  of  relationships  between  identifiers.  For 
example,  data  on  the  links  of  an  exposure  to  a  hazard  may  be 
said  to  be  describing  the  characteristics  of  the  relationship 
between  an  employee,  a  hazard,  and  a  facility  (i.e.,  three 
types  of  identifiers  that  constitute  the  forms  units  for  this 
data  element  type).  While  in  many  (perhaps  most)  cases  only 
one  type  of  identifier  will  be  described  by  the  DS11  data,  up 
to  six  forms  unit  types  have  been  allowed  because  an  extensive 
evaluation  has  shown  that  this  is  the  maximum  credible  number 
of  forms  units  that  are  likely  to  be  needed  to  describe  the 
most  complex  type  of  relationships  between  identifiers. 

The  location  of  the  values  for  the  forms  units  for  a  given 
forms  subpart  on  a  set  of  completed  forms  data  (DS14)  are 

prescribed  in  versions  of  a  form  given  on  the  forms 

description  data  (OSIO)  and  linked  to  the  forms  subpart  data 
for  that  specification  (version)  of  the  form.  The  program 
will  check  that  the  types  of  forms  units  given  in  the  DS10 

data  for  a  particular  use  of  the  forms  subpart  data  on  a 

version  of  a  form  are  consistent  with  the  DS11  data. 

5.  Data  element  type  code  (CT4)  for  each  of  the  up  to  6  data 
element  types  that  may  make  up  a  set  of  forms  subpart  data. 

The  sequence  (i.e.,  I  through  6)  in  which  each  of  the  data 
element  types  on  the  DS11  data  is  entered  is  important.  It  is 
this  sequence  that  is  used  in  other  data  sets  that  is  used  to 
identify  a  particular  data  element  type  on  a  particular  set  of 
forms  subpart  data.  Also  the  order  in  which  the  data  elements 
are  to  be  printed  out  on  a  form  is  known  from  this  sequence. 
The  same  data  element  types  in  a  different  order  would  be 
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shown  on  a  different  set  of  DS11  data.  Similarly,  a  given 
data  element  type  may  be  more  than  one  set  of  DS11  data  (Only 
the  combination  of  up  to  six  data  elements  is  unique.) 

The  reason  why  the  forms  subparts  are  described  in  sets  of  six 
data  element  types,  instead  of  individual  data  element  types, 
is  that  many  times  the  same  group  of  data  elements  will  be 
used  together,  e.g.,  employee  name  and  Social  Security 
Numbers;  visual  acuity  in  the  right  and  left  eye;  the  three 
dimensions  of  a  facility  or  object;  etc.  By  referring  to  the 
forms  subpart  identifier  (1017)  the  user  can  easily  prescribe 
the  contents  of  a  form  (in  the  DS10  data)  and  ensure  that  the 
same  format  for  common  groups  of  data  elements  is  used.  Also 
many  times  allowable  limits  can  only  be  specified  in  terms  of 
the  relationships  between  two  or  more  data  elements.  As 
allowable  limits  are  specified  for  a  given  forms  subpart  (see 
allowable  limits  specification  data  ( DS17 ) ) ,  this  grouping 
together  of  data  element  types  is  advantageous  for  allowable 
limits  specification  data  processing  as  well. 

For  each  of  the  up  to  6  data  element  types  given  above,  the 
exact  wording  of  the  question  or  statement  that  is  to  appear 
on  printed  OHMIS  forms  for  this  data  element  type  and  is  to  be 
used  to  obtain  the  information  desired  when  completing  the 
form.  Includes  special  instructions  or  examples  for  providing 
information  about  the  data  element  type. 

For  each  of  the  up  to  6  data  element  types  given  above, 
whether  or  not  the  data  element  is  the  type  for  which  there 
can  be  more  than  one  value,  i.e.,  the  type  for  which  the  value 
can  change.  Answer:  Yes/No.  This  information  comes  from  the 
data  element  type  information  (DS7)  data  on  the  data  element 
type.  Data  element  types  which  cannot  change  and  for  which 
there  will  not  be  multiple  values  for  the  same  forms  unit  are 
referred  to  as  'one  time  data  entries'.  An  example  is  'Date 
of  Birth' ;  each  employee  can  only  have  one  date  of  birth  and 
it  can  never  change  (although  it  can  be  corrected).  This 
characteristic  of  the  data  element  type  is  used  to  determine 
whether  or  not  to  assign  a  Data  Element  Sequence  Number  to 
each  entry  of  a  value  for  the  data  element  type  for  a  given 
forms  unit..  (See  description  of  Data  Element  Sequence  Number 
on  the  completed  forms  data  (DS14)  description.)  Also, 
although  it  is  possible  that  a  nonchanging  data  entry  will  be 
entered  more  than  once  (for  example  several  forms  may  have  a 
person's  date  of  birth  on  them)  this  information  informs  the 
OHMIS  program  about  whether  to  actually  enter  the  data  onto 
the  OHMIS  data  base  each  time  it  appears  on  a  form. 


For  each  of  the  up  to  6  data  element  types  given  above, 
whether  or  not  this  type  of  data  is  to  be  considered  to  have 
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'base  line'  information.  Answers:  Yes/No.  Answers  of  'No' 
are  referred  to  as  'no  base  line  data  entries'.  If  the  answer 
for  the  same  data  element  type  given  above  was  'No'  (i.e.,  the 
data  element  type  is  a  'one  time  data  entry'),  then  the  answer 
in  this  field  must  also  be  'No'  ('no  base  line  data  entry'). 
Base  line  data  is  data  used  to  measure  the  characteristics  of 
an  employee  or  other  unit  prior  to  exposure  or  prior  to 
employment  with  the  Department  of  the  Army.  More  generically, 
base  line  data  is  the  data  that  is  to  be  treated  as  the  first 
entry  of  data  of  that  data  element  type  for  a  given  unit.  It 
is  used  to  compare  changes  in  the  values  of  that  data  element 
type  for  that  unit  over  time.  For  example,  one  result  of  a 
hearing  test  (a  data  element  type)  for  an  individual  employee 
(a  unit)  may  be  compared  to  the  original  hearing  test  results 
(base  line  data)  for  that  employee  in  evaluating  allowable 
limits.  Therefore,  hearing  test  results  are  the  type  of  data 
that  do  have  base  line  information  and  the  answer  in  the  field 
would  be  'Yes'.  Base  line  information  about  a  data  element 
type  is  entered  by  the  user.  If  the  data  element  type  is  a 
'one  time  data  entry'  (see  above),  the  program  automatically 
designates  the  data  element  type  as  a  'no  base  line  data 
entry',  because  obviously  the  concept  of  'base  line'  is 
meaningless  for  data  element  types  with  values  that  cannot 
change.  However,  there  may  be  some  data  element  types  that  do 
change  or  that  could  have  base  line  information,  but  which  the 
user  does  not  wish  to  be  treated  as  the  type  of  data  element 
that  has  base  line  information  when  it  is  used  in  the  forms 
subpart  data  described  in  this  DS11  data  set. 
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Forms  Applicability  Factors  Data 


This  data  describes  the  types  of  factors  that  determine  which 
specification  of  a  form  should  be  used  for  a  particular  type  of  form 
(CT9)  and  OHMIS  service  area  (1010).  For  example,  if  a  user  wishes  to 
use  a  different  pre-employment  physical  depending  on  the  job  class  of 
the  employee  being  hired,  then  'job  class'  would  be  the  factor 
determining  which  version  of  the  pre-employment  physical  should  be  used. 
This  factor  would  appear  on  DS12  data.  The  data  is  entered  by  the  user 
using  Menu  Selection  Sequence  2.3.1. 

Only  current  DS12  data  is  maintained.  The  data  is  undated  (i.e.,  no 
begin  or  end  dates).  There  can  only  be  one  set  of  DS12  data  for  each 
form  type  (CT9)  and  OHMIS  service  area  identifier  ( I  DIO )  at  a  time.  The 
new  DS 12  data  is  entered  (using  Menu  Selection  Sequence  2.3.1)  and  the 
program  checks  to  see  that  the  DS12  data  for  the  form  type  and  service 
area  does  not  already  exist.  If  it  does,  the  program  asks  the  user 
whether  the  existing  data  is  to  be  deleted  or  changed  (Menu  Selection 
Sequence  2.3.2  or  Menu  Selection  Sequence  2.3.3).  DS12  data  can  be 
deleted  or  changed  provided  that  the  existing  forms  applicability  values 
data  (0S13)  that  corresponds  to  the  DS12  data,  i.e.  all  applicability 
values  for  the  same  type  of  form  (CT9),  is  also  changed  to  be  consistent 
with  the  new  DS12  data. 

1.  Form  type  code  (CT9)  for  the  type  of  form  for  which  this 
data  is  provided. 

2.  OHMIS  service  area  identifier  (1010)  for  the  service  area 
specifying  this  data. 

3.  Identifier  type(s)  (CT10)  or  data  element  type(s)  (CT4)  for 
from  1  to  5  types  of  units  about  which  there  are  factors  that 
determine  the  appl icabi 1 i ty  of  the  form.  In  the  above  example 
where  the  job  class  of  the  potential  new  hire  is  the  factor 
which  determines  which  version  of  the  pre-employment  physical 
type  of  form  will  be  applicable,  the  unit  (type  of  identifier) 
would  be  an  employee,  because  the  factor  (job  class)  is  a 
characteristic  describing  employee.  There  may  be  up  to  five 
such  applicability  units  determining  the  applicability  of  a 
form.  Note:  These  units  are  not  necessarily  the  same  as  the 
forms  unit  referred  to  in  the  forms  subpart  data  (DS11)  and 
forms  specification  data  ( DS 10 ) .  These  units  determine  the 
applicability  of  a  version  of  a  form,  while  the  forms  units 
define  the  applicability  of  allowable  limits  for  the  data  on  a 
form  and  the  type  of  unit  being  described  by  the  data  on  a 
form. 

4.  For  each  of  the  above  appl icabi 1 i ty  units  (1  to  5),  up  to  5 
data  element  type  codes  (CT4)  or  identifier  type  codes 

describing  tne  characteristics  of  these  units  which 


determine  the  applicability  of  the  form.  In  the  above 
example,  job  class  identifiers  are  the  type  of  data  element 
(identifier  type)  that  is  the  characteristic  determining  the 
applicability  of  the  form.  There  may  be  up  to  five  such 
characteristics  for  each  of  the  up  to  5  units  referenced 
above. 
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Forms  Applicability  Values  Data 


This  data  prescribes  a  given  set  of  ranges  of  values  (or  identifiers) 
that  determine  the  appl icabil ity  of  a  particular  specification  of  the 
form.  The  values  data  on  DS13  matches  the  format,  i.e.  the  data 
element  types  (CT4)  and  identifier  types  (CT10),  given  in  the  forms 
applicability  factors  data  (DS12)  for  the  same  type  of  form  (CT9)  and 
0HM1S  service  area  (1010). 

There  can  be  multiple  sets  of  DS13  data  for  a  given  forms  specification 
(1D16)  and  OHMIS  service  area  ( I DIO ) .  If,  for  example,  a  particular 

form  specification  is  applicable  if  'A'  or  1 B 1  are  true,  then  there 
would  be  two  different  sets  of  DS13  data  (one  for  applicability  value 
'A1  and  one  for  ' B ' )  each  referring  to  the  same  form  specification 
identifier  (ID16)  and  OHMIS  service  area  (ID10).  If  the  forms 
spec  if icat ion  were  applicable  only  if  'A1  and  1 B 1  were  true,  this 
would  be  shown  on  the  same  single  set  of  DS13  data. 

However,  the  reverse  is  not  true.  There  cannot  be  the  exact  same  0S13 
data  for  more  than  one  set  of  forms  specification  (version)  data  (DS10) 
of  the  same  form  type  (CT9)  for  a  given  service  area  (ID10),  nor  can 
the  range  of  values  given  in  one  set  of  DS13  data  overlap,  e.g.,  one  set 
of  applicability  values  (DS13)  specifies  that  a  forms  specification 
applies  whenever  the  employee  is  over  age  50  while  another  set  of  DS13 
data  says  that  a  different  forms  specification  applies  whenever  the 
employee  is  between  age  40  and  age  60.  The  reason  these  values  are  not 
acceptable  is  that  they  would  mean  that  the  data  was  stating  that  more 
than  one  different  version  of  a  given  type  of  form  is  applicable  in  a 
given  circumstance,  i.e.,  the  program  would  not  be  able  to  "decide" 
which  form  to  use.  The  program  checks  for  this  internal  consistency 
problem  using  the  list  of  forms  specification  identifiers  by  form  type 
and  by  OHMIS  service  area  ( DL13 )  when  the  user  enters  0S13  data  using 
Menu  Selection  2.4.1. 

Only  current  DS13  data  is  maintained.  DS13  data  may  be  changed  (Menu 
Selection  2.4.3)  or  deleted  (Menu  Selection  Sequence  2.4.2)  as  long  as 
it  follows  the  format  (i.e.,  the  same  set  of  data  element  types  or 
identifier  types)  as  that  prescribed  in  the  current  DS12  data  for  the 
form  type  and  OHMIS  service  area  and  remains  not  duplicating  or 
overlapping  with  a  different  set  of  DS13  data  referring  to  a  different 
form  version.  The  DS13  data  is  undated  (i.e.,  no  begin  or  end  dates). 

1.  Forms  application  identifier  (ID19).  A  unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS13  data. 

2.  Form  type  code  (CT9)  for  the  type  of  form  for  which  this 
DS13  data  is  being  given. 

3.  Forms  specification  identifier  (ID16)  for  the  particular 
form  description  (versions  shown  on  a  set  of  DS10  data)  for 
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which  this  DS13  data  describes  the  form's  app] icabi ] i ty. 

That  is,  this  is  the  version  of  the  form  that  will  be  used  if 
the  units  and  characteristics  for  which  the  form  is  being 
generated  match  the  applicability  values  given  in  this  set  of 
DS 13  data. 

4.  OHMIS  service  area  identifier  ( I  DIO )  for  which  this  set  of 
applicability  values  (DS13)  is  being  generated. 

5.  The  OHMIS  user  identifier  (ID13)  for  the  person  prescribing 
this  applicability  data  for  the  form. 

6.  The  employee  identifier  (ID4)  for  the  above  person. 

7.  The  range  of  applicability  values  or  identifiers,  if  any, 
for  each  of  the  up  to  5  identifier  types  (CT10)  or  data 
element  types  (CT4)  which  have  been  identified  in  the  forms 
appl icabi 1 i ty  factors  data  (DS12)  as  being  the  applicability 
units  for  the  above  referenced  form  type  (CT9)  and  OHMIS 
service  area  (1010).  (See  the  (information  triggered) 
requirements  applicability  data  (DS3)  for  a  description  of  how 
ranges  of  values  are  entered.)  This  data  can  be  blank  if  this 
particular  application  of  the  form  does  not  depend  on  a 
particular  type  of  unit,  i.e.,  it  is  the  characteristics  of 
the  unit  rather  than  the  identification  of  the  unit  that 
determine  the  applicability  of  the  version  of  the  form. 

8.  Same  as  above  (i.e.,  the  range  of  applicability  values)  for 
the  up  to  5  characteristics  of  each  of  the  up  to  5  units 
referenced  above.  For  example,  if  it  had  been  determined  that 
the  version  of  the  pre-employment  physical  type  of  form  to  be 
used  depended  on  the  job  class  for  which  the  new  employee  was 
being  hired,  this  data  would  provide  the  particular  job  class 
or  range  of  job  class  identifiers  (ID7)  for  which  the  above 
referenced  specif ication  of  the  pre-employment  physical  (i.e., 
for  the  above  forms  specification  identifier  ( ID16 ) )  is 
applicable.  In  this  example,  the  appl icabi 1 i ty  values  shown 
above  for  the  type  of  appl icabi 1 ity  unit  (i.e.,  an  employee) 
would  probably  be  blank  (i.e.,  no  range  of  employee 
identifiers  would  be  given  above),  because  it  is  unlikely  that 
there  would  be  a  different  version  of  the  form  for  different 
individual  employees.  In  other  words,  in  this  example  it  is 
not  the  identity  of  the  unit  (i.e.,  the  first  range  of 
values  referred  to  above)  that  determines  the  applicability  of 
the  form,  but  the  characteristics  of  the  unit  (i.e.,  this 
second  set  of  ranges  of  values). 
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Completed  Forms  Data  (Generic  Description  of  'Blank*  Form) 


This  data  set  describes  the  characteristics  of  a  set  of  data  entered 
for  a  form  generated  through  the  OHMIS  system,  i.e.  for  the  blank  form 
(output  012)  generated  in  Function  F3A  from  forms  specification  data 
(DS10).  (See  output  012,  the  OHMIS  'Blank'  Form  for  a  generic 
description  of  all  OHMIS  outputs  that  are  forms.;  Although,  of  course, 
each  type  of  form  and  each  speci f ication  for  a  form  will  be  different, 
all  OHMIS  data  entry  forms  will  follow  a  common  format.  This  format  is 
described  in  the  DS14  data.  A  common  format  is  used  in  order  to  allow 
the  user  flexibility  in  generating  his/her  own  forms  (see  Function  3A) 
and  to  enable  a  single  set  of  data  processing  procedures  for  checking 
data  entered  on  a  form  to  determine  if  it  matches  allowable  limits  to  be 
used  for  a  wide  variety  of  forms. 

The  data  from  any  completed  OHMIS  form  (i.e.,  DS14  data)  is  entered  by 
the  user  in  one  program  using  Menu  Selection  3.1.  Some  DS14  data  is 
derived  from  the  forms  specification  data  (DS10)  with  a  corresponding 
forms  specification  identifier  (ID16).  (See  function  F3B  for  the 
processing  involved  in  entering  data  for  a  form;  this  process  includes 
checking  for  whether  the  data  entries  are  matching  allowable  limits.) 

DS14  data  is  maintained  indefinitely.  Individual  archiving  decisions 
will  be  made  depending  on  the  type  of  form  (CT9)  covered  by  the  DS14 
data.  In  some  instances  it  may  be  required  to  keep  the  hard  copy  of  the 
actual  data  entry  form  (012).  The  length  of  time  for  this  archiving  is 
given  in  the  DS1U  data.  QS14  data  may  be  deleted  (using  Menu  Selection 
Sequence  3.2)  or  changed  (Menu  Selection  Sequence  3.3). 

Although  the  decision  on  the  file  and  storage  structure  for  the  OHMIS 
data  base  awaits  the  final  detailed  program  design  and  logic,  it  is 
convenient  to  think  of  the  majority  of  OHMIS  data  stored  in  a  structure 
based  on  the  OHMIS  forms  generated  by  the  user  and  defined  in  the  DS14 
data  set.  Thus,  for  one  class  of  data  (for  example,  data  on  medical 
history)  there  would  be  a  particular  type  of  form  (e.g.,  FT4  medical 
history  form).  The  user  would  define  the  specifications  (data  elements 
contained  in  the  form)  that  make  up  this  form  using  DS10  data.  More 
than  one  specification  (version)  of  the  medical  history  form  could  be 
specified  by  the  user,  if  it  is  desired  to  have  different  versions  for 
different  users  (applicability  factors)  of  the  form.  Each  version  of 
the  form  becomes  a  format  for  the  way  in  which  this  class  of  data  is 
stored,  i.e.,  the  means  of  specifying  how  to  locate  a  value  for  a 
specific  data  element  type  in  the  OHMIS  data  base. 

Each  form  has  one  or  more  forms  units  identified  at  the  top  of  the 
form  (the  beginning  of  the  DS14  data  set)  indicating  what  unit  is  being 
described  by  the  class  of  data  in  the  form  (e.g.,  the  medical  history 
data  would  describe  an  individual  employee).  For  some  types  of  forms  it 
is  possible  tnat  there  would  be  more  than  one  set  of  data  for  a  given 
type  of  form  entered  on  a  given  unit,  e.g.  a  civilian  DA  employee  may 
have  medical  history  data  entered  periodically  to  update  the  OHMIS  data 
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base  for  treatments  and  diagnoses  received  from  other  than  DA  medical 
data  on  a  facility  will  almost  certainly  be  entered.  Thus  for  a  given 
class  of  data  (medical  history  data)  and  a  given  unit  (an  employee  or 
a  facility)  the  OHMIS  data  base  may  contain  a  series  of  sets  of  data 
entries .  The  format  for  entering  and  storing  each  set  of  data  in  a 
series  is  defined  by  the  version  of  the  form  (DS10  data);  the  generic 
format  for  entering  Completed  Forms  Data  [ Generic  Description  of 
'Blank1 ]  and  storing  the  values  of  the  data  from  forms  is  defined  in 
this  description  of  the  DS14  data.  The  ability  to  refer  to  a  particular 
set  of  DS14  data  in  the  series  of  data  for  a  given  class  of  data  and 
unit  (i.e.,  a  particular  set  of  data  entered  from  a  given  form)  is 
accomplished  with  the  completed  forms  identifier  (ID16).  Each  set  of 
data  entered  onto  the  OHMIS  data  base  from  an  OHMIS  form  is  assigned  an 
completed  forms  identifier.  (Here  the  word  "form"  is  used  loosely  and 
can  be  a  screen  on  a  computer  terminal  as  well  as  a  hard  copy  data  entry 
form.)  The  allowable  limits  evaluation  of  data  to  determine  if  the  data 
entered  on  a  form  matches  a  specified  allowable  limit  will  often  involve 
comparing  one  set  of  data  in  the  series  (one  set  of  data  for  a  given 
class  of  data  and  given  unit)  with  another  set  of  data  in  the  same 
series.  In  order  to  describe  a  common  allowable  limits  evaluation  for 
all  data,  it  is  convenient  to  think  of  each  set  of  data  for  a  form 
(i.e.,  each  of  data  of  a  given  class  and  for  a  given  unit)  stored 
separately  as  a  whole  using  the  structure  given  in  the  format  of  the 
form  by  the  DSiU  data.  The  use  of  the  device  of  the  format  of  a  form  as 
a  means  of  describing  data  storage  enables  the  location  of  the  values 
for  any  data  element  type  for  any  particular  unit  in  the  OHMIS  data  base 
to  be  defined  generically.  This  is  the  reason  why  the  description  of 
the  completed  forms  data  (DS14)  is  given;  it  is  the  generic  description 
of  how  any  set  of  data  entered  using  an  OHMIS  form  would  be  stored.  The 
definition  of  this  "common  storage  and  format"  method  for  almost  all 
OHMIS  data  enables  the  processing  functions  of  OHMIS,  such  a<:  the  check 
for  allowable  limits  and  the  triggering  of  follow  up  actions  that  result 
from  the  entry  of  a  given  set  of  data  to  also  be  defined  generically. 

To  avoid  confusion  it  should  be  noted  that  the  completed  forms  (DS14) 
data  describes  generically  a  possible  storage  method  of  all  OHMIs 
data  entered  by  an  OHMIS  form,  while  output  012  (OHMIS  'Blank'  Form 
( generic) )  describes  the  way  an  OHMIS  data  entry  form  would  look  to  a 
user  when  presented  for  data  entry.  The  two  descriptions  are  thus  very 
similar,  but  serve  different  purposes;  the  first  (DS14)  describes  a 
generic  storage  method  (in  order  to  enable  other  OHMIS  functions  to  be 
described  generically)  and  the  second  012  describes  an  output. 

Identification  Data 


1.  Completed  form  identifier  (ID18).  Unique  value  assigned  by 
the  program  to  distinguish  this  set  of  DS14  data,  i.e.,  to 
distinguish  a  particular  set  of  data  entered  onto  the  OHMIS 
data  base  from  a  particular  completed  form. 

Previous  completed  form  identifier  t I D1 8 ) .  This  is  the  ID18 
for  the  last  form  entered  onto  the  OHMIS  data  base  for  the 
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same  forms  unit  identifier  (see  below)  and  for  the  same  form 
type  (CT9);  need  not  be  the  same  form  specif ication 
(ID16)).  This  identifier  is  obtained  from  the  current  forms 

list  (DL23)  at  the  time  -hat  the  DS14  data  is  entered  and  the 

above  new  ID18  replaces  this  previous  ID18  on  the  DL23. 

3.  Forms  type  code  (CT9)  for  the  type  of  form  for  which  data  is 

being  entered. 

4.  Forms  specification  identifier  (ID16)  for  the  particular 
version  of  the  above  form  for  which  data  is  being  entered. 

5.  OHMIS  service  area  (ID10)  for  which  this  form  was  completed. 
The  program  will  check  that  the  ID16  and  I DIO  are  consistent. 

6.  Date  data  obtained  or  date  of  the  event  covered  by  the  form, 

e.g.,  the  date  that  a  sample  was  taken.  This  is  not  the 
date  that  the  form  was  completed  or  the  date  that  it  was 
entered  onto  the  computer.  In  the  allowable  limits 
evaluations  in  which  the  time  span  is  at  issue  (e.g.,  an 
allowable  limit  of  no  more  than  'X'  entries  over  a  specified 
period  of  time),  it  is  this  date,  not  the  date  that  the  form 

was  completed  or  the  date  that  it  was  entered,  that  is  used. 

For  some  form  types  the  time  (hour,  minute,  second)  at  which 
the  data  was  obtained  may  also  be  entered.  This  is  used  in 
allowable  limits  evaluations  that  are  specified  in  terms  of  a 
time  span  of  less  than  a  day. 

7.  Date  form  was  completed. 

8.  Length  of  time  that  the  hard  copy  of  this  form  is  to  be 

maintained  from  the  date  the  data  was  obtained  (above).  The 

data  for  this  field  is  from  the  DSIO  data  corresponding  to  the 
above  forms  specification  identifier  (ID16).  Answer  may  be 
’O’ . 

9.  OHMIS  user  identifier  (ID13)  or  position  identifier  (ID14), 
if  any,  of  the  person  completing  the  form.  The  program  will 
check  that  this  person  is  the  same  type  of  user/position  (CT1 
or  CT2)  as  specified  in  the  DSIO  data,  if  any,  and  will  note 
that  this  is  different. 

10.  Employee  identifier  (ID4)  of  the  person  completing  the  form. 

11 .  OHMIS  user  identifier  (ID13)  or  position  identifier  (ID14), 
if  any,  of  the  person  who  reviewed  ('signed  off  on1)  this 
form.  The  program  will  check  for  consistency  with  the  CT1  or 
CT2  provided  in  the  DSIO  data  for  the  person  who  was  supposed 
to  have  reviewed  the  form  and  note  differences. 

12.  Employee  identifier  (ID4)  for  the  person  who  reviewed  this 


form. 
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13.  Date  this  form  was  reviewed  or  "signed  off  on." 

14.  The  forms  units  identifiers  (or  possibly  data  element 
values)  of  a  person  or  thing  (unit)  for  which  the  data  in  this 
form  is  being  completed.  For  example,  if  the  form  were  a 
pre-employment  physical,  the  unit  for  which  the  form  would  be 
completed  would  be  an  employee  identifier  (ID4).  The  DS10 
data  specifies  the  type  of  identif ier( s)  (CT10)  or  data 
element  types  (CT4)  that  are  to  be  entered  here.  Up  to  nine 
such  identifiers  may  be  entered. 

Form's  Content 

15.  The  values  for  the  data  entries  on  the  form,  that  is  the 
values  for  the  up  to  6  data  elements  on  the  up  to  2475  sets  of 
data,  i.e.,  the  up  to  99  sets  of  up  to  25  different  forms 
subparts  data  (DS11)  defined  by  the  DS10  as  being  included  on 
this  version  (specification)  of  the  form.  It  is  not 
anticipated  that  any  form  will  actually  have  the  total  length 
of  2475  forms  subparts;  and,  it  is  not  anticipated  that  a 
maximum  record  length  for  all  forms  will  be  used  that  is  the 
same  for  all  forms.  Instead  it  is  envisioned  that  the  actual 
length  of  the  record  for  storing  data  from  a  given  form 
specification  (form  type  (CT9)  and  version  ( ID16 ) )  will  be 
defined  in  the  DS10  data.  This  is  assuming  that  the  final 
determination  on  data  storage  is  to  use  the  format  of  forms 
defined  in  DS10  data. 

16.  For  each  of  the  above  values  for  data  element  types,  the  Data 
Entry  Sequence  Number.  This  is  the  number  indicating  the 
frequency  and  order  with  which  data  entries  of  the  same  data 
element  type  and  for  the  same  forms  unit  identifier  have  been 
made.  For  example,  there  may  be  more  than  one  entry  of  a 
vision  test  result  (data  element  type)  for  an  individual 
employee  (forms  unit  identifier).  The  first  entry  ever  made 
to  the  OHMIS  data  base  for  this  data  element  type  and  for  this 
employee  would  be  assigned  Data  Entry  Sequence  Number  *1';  the 
next  time  this  same  data  element  type  was  entered  for  the  same 
person,  it  would  be  assigned  a  sequence  number  of  '2',  etc. 

If  the  forms  subpart  data  (DS11)  for  this  data  element  type 
has  identified  this  data  element  type  as  a  ’one  time  data 
entry'  (such  as  date  of  birth)  the  sequence  number  is  not 
assigned.  Instead  a  Data  Entry  Sequence  Number  code  (e.g., 
'X')  is  used  to  indicate  that  this  is  a  type  of  data  element 
that  does  not  have  a  sequence  of  entries  for  it.  If  the  data 
element  type  was  not  completed  for  this  entry  of  completed 
forms  data  (DS14),  i.e.,  if  it  were  left  blank  on  the 
particular  form  being  entered  in  this  set  of  DS14  data,  the 
Data  Entry  Sequence  Number  is  left  blank  also  (i.e.,  the 
sequence  number  is  not  incremented).  (These  missing  data 
elements  are  entered  on  the  missing  data  element  information 
(DS19)  for  use  in  tracking  missing  information;  the  user  must 
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enter  a  value,  e.g.,  "unknown"  or  "not  applicable"  for  the 
computer  program  to  consider  data  not  to  be  missing.) 

The  Data  Entry  Sequence  Number  is  identified  by  the  program, 
not  the  user.  It  is  obtained  using  the  previous  completed 
form  identifier  (ID18)  given  above  (which  in  turn  was  derived 
from  the  current  forms  list  (DL23)).  Using  the  two  ID18s  on 
each  set  of  completed  forms  data  (DS14),  the  program  searches 
the  previously  entered  date  for  the  same  type  of  form  (CT9) 
and  forms  unit  identifier  in  reverse  order  of  the  order  in 
which  the  forms  were  completed  until  an  entry  for  the  same 
data  element  type  is  found.  The  Data  Entry  Sequence  Number 
that  was  assigned  to  that  data  entry  of  a  data  element  type  is 
then  incremented  by  '1*  and  assigned  to  the  new  data  entry  for 
the  same  data  element  type  and  same  forms  unit  identifier.  It 
is  possible  that  there  would  be  no  previous  entries  of  the 
same  data  element  type  (on  the  same  type  of  form  (CT9))  for 
the  same  form  unit  identifier.  This  would  be  the  case  if 
there  were  no  previous  forms  of  this  form  type  (CT9)  for  this 
forms  unit.  It  would  also  be  the  case  if  the  previous  form  of 
the  same  type  and  for  the  same  unit  was  a  different  version 
(forms  specification  as  given  in  the  DS10  data  and  identified 
by  the  forms  specification  identifier  ( ID16 ) )  for  this  form 
type  and  that  version  does  not  include  the  data  element  type 
being  entered.  Finally,  it  would  be  the  case  that  there  would 
be  no  previous  entry  of  the  same  data  element  type  for  the 
same  unit  even  if  there  was  a  previous  form  of  the  same 
specif ication,  if  the  user  had  not  completed  this  data  element 
type  on  the  previous  form,  i.e.,  it  was  a  missing  data 
element. 

The  Data  Entry  Sequence  Number  is  used  to  enable  comparisons 
between  and  evaluation  of  trends  among  entries  of  data  for  the 
same  forms  unit  identifier  (e.g.,  for  the  same  employee)  as  a 
part  of  evaluating  tne  data  entered  to  determine  if  it  matches 
any  allowable  limits  specifications. 

For  each  of  the  above  values  for  data  element  types  that  are 
not  'no  base  line  data  entry'  data  element  types  (as 
determined  from  the  DS11  data),  whether  or  not  this  entry  is 
an  original  base  line  value  or  a  'secondary  base  line'  value. 
For  any  value  of  a  data  element  type  entered  in  OHMIS  (except 
the  'no  base  line  data  entry'  types  of  data  elements)  the 
value  with  the  Data  Entry  Sequence  Number  of  ' 1 ‘  is  the 
original  base  line.  If  this  is  a  value  for  a  ‘no  base  line 
data  entry'  type  of  data  element,  then  the  base  line  field  is 
left  blank.  ' Secondary  base  lines'  are  assigned  by  the  user. 
These  represent  a  new  base  line  for  a  given  data  element  type 
and  forms  unit  identifier  that  was  completed  later  than  the 
original  base  line.  An  example  of  the  use  of  categorizing  a 
data  entry  as  a  secondary  base  line  would  be  the 
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identification  of  an  appropriate  set  of  base  line  data  for  an 
individual  who  has  been  rehired  after  a  long  period  away  from 
the  Department  of  the  Army  or  has  been  hired  into  a  very 
different  job.  If  this  was  the  case,  the  user  may  wish  to 
assign  the  data  entry  obtained  at  the  time  that  the  employee 
was  rehired  as  the  ' secondary  base  line'  (i.e.,  the 
data  entry  that  is  to  be  treated  as  a  base  line)  rather  than 
use  the  original  base  line  (the  first  entry  of  this  data 
element  type  for  this  employee)  as  the  base  line.  Similarly 
the  user  may  wish  to  set  a  new  base  line  for  monitoring 
changes  in  amounts  of  hazardous  substances  after  a  major 
change  in  hazardous  material  storage  procedures  or  another 
major  change  in  corrective  actions. 

The  user  indicates  that  a  value  for  a  data  element  type  is  to 
be  considered  a  ‘secondary  base  line'  at  the  time  that  the 
DS14  data  is  entered,  i.e..  Function  F38.  The  identification 
of  any  previous  entries  as  original  base  line  entries  or 
previous  secondary  base  line  entries  is  retained  in  the  OHMIS 
data  base  throughout  the  system  even  if  several  secondary  base 
line  entries  are  identified. 

The  identification  of  entries  as  base  line  entries  (original 
or  secondary)  is  used  primarily  to  enable  the  evaluation  of 
allowable  limits  as  many  allowable  limits  are  defined  in  terms 
of  the  relationship  of  an  entry  to  the  base  line  entry  of  the 
same  data  element  type  for  the  same  unit.  The  automatic 
allowable  limits  evaluation  that  takes  place  when  data  is 
entered  from  an  OHMIS  form,  i.e.,  in  Function  F3B.  Uses 
either  the  original  base  line  or  the  latest  secondary  base 
line  as  the  base  line  entry  in  the  allowable  limits  check 
(Function  F3C),  which  allows  for  a  manual  evaluation  of 
allowable  limits;  the  user  may  specify  which  secondary  base 
line  entry  is  to  be  used  to  determine  if  there  is  a  match  to 
the  allowable  limit. 
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Allowable  Limits  Applicability  Factors  Data 


This  data  identifies  the  factors  (data  element  types)  that  are  to  be 
used  to  determine  which  set(s)  of  allowable  limits  specification  data 
(DS17)  are  to  be  used  in  evaluating  whether  a  data  entry  on  a  form  is 
outside  the  allowable  limits.  For  example,  if  an  allowable  limit  for 
weight  of  an  employee  was  to  depend  on  a  person's  age,  then  employee  age 
would  be  a  factor  determining  which  set  of  allowable  limits  should  be 
used.  The  values  for  these  factors  (e.g.,  the  age  value  that  determines 
the  applicability  of  a  particular  set  of  allowable  limits)  are  given  in 
the  allowable  limits  applicability  values  data  (DS16). 

Allowable  limits  specification  data  (D517)  is  provided  to  cover  either 
individual  data  elements  (e.g.,  an  allowable  limit  for  the  weight  of  an 
employee),  in  which  case  the  allowable  limit  refers  to  a  forms  subpart 
identifier  (1D17)  i.e.,  the  set  of  up  to  6  interrelated  data  elements; 
or  an  allowable  limits  specif ication  may  refer  to  an  entire  form  (e.g., 
an  allowable  limit  on  the  number  of  Hazardous  Substance  Incident  Reports 
that  can  be  entered  for  a  facility  without  triggering  a  requirement),  in 
which  case  the  allowable  limit  refers  to  a  forms  specification 
identifier  (1016). 

DS15  data  is  entered  by  the  user  using  Menu  Selection  Sequence  4.2.1. 
Only  current  DS15  data  is  maintained.  Data  may  be  deleted  (Menu 
Selection  Sequence  4.2.2)  or  changed  (Menu  Selectiun  Sequence  4.2.3) 
provided  any  existing  allowable  limits  applicability  values  data  (DS16) 
that  corresponds  to  the  DS15  data  being  deleted,  i.e.,  all  applicability 
values  for  the  same  forms  subpart  identifier  (ID17)  or  forms 
specif ication  identifier  (ID16),  are  deactivated  and  new  DS16  data  is 
generated  that  is  internally  consistent.  There  can  only  be  one  set  of 
DS15  data  for  a  given  forms  subpart  identifier  (ID17)  (or  forms 
specification  identifier  ( ID16 ) )  and  OHMIS  service  area  (ID10)  at  a 
time.  The  program  checks  for  this  in  the  same  way  described  for  forms 
applicability  values  data  (DS12). 

It  should  be  noted  that  it  is  possible  that  there  are  no  factors  that 
determine  the  applicability  of  an  allowable  limit,  i.e.,  there  is  only 

one  set  (or  only  one  :eries  of  sets)  of  allowable  limits  specification 

data  (0S17)  for  a  given  set  of  forms  subpart  data  (DS11)  (or  forms 

description  data  ( DS 10 ) )  in  an  OHMIS  service  area  (ID10)  and  these  same 

limits  apply  in  all  cases.  For  example,  if  the  allowable  limit  for 
weight  was  not  dependent  on  employee  age  or  sex  or  any  other  factor 
there  would  be  no  allowable  limits  applicability  factors  data  for  that 
data  element.  In  this  situation,  there  would  be  no  DS 15  data  or 
allowable  limits  applicability  values  data  (DS16)  for  the  forms  subpart 
in  the  OHMIS  service  area.  The  allowable  limits  evaluation  program 
(Function  F3B)  would  not  need  to  determine  which  allowable  limits  were 
applicable  but  would  use  the  1  default1  allowable  limits  specif ication 
data  (0S17)  as  the  allowable  limit  with  which  to  compare  the  data  entry 
in  order  to  determine  if  allowable  limits  have  been  reached. 


It  should  be  noted  that  the  0S17  default  data  is  different  than  the 
default  data  for  forms  (i.e.,  the  default  DS10  data).  Because  there 
must  be  an  applicable  form  of  each  type  of  form  for  each  OHMIS  service 
area,  the  default  DS10  data  is  used  both  when  there  are  no  forms 
applicability  data  (DS12  and  DSI3)  given  (because  the  same  form  is  used 
for  all  applications)  and  when  none  of  the  forms  applicability  data 
given  are  found  to  match  the  specified  values  for  the  forms 
applicability  characteristics .  This  is  because  there  must  be  a  default 
DS10  data  for  each  form  type  and  OHMIS  service  area.  There  need  not, 
however,  be  any  allowable  limit  (DS17  data)  for  a  form  subpart  and  OHMIS 
service  area.  This  means  that  there  need  not  be  a  default  DS17  data  for 
each  forms  subpart  (or  form)  and  OHMIS  service  area;  and  if  there  is  a 
set  or  series  of  sets  of  default  DS17  data  it  is  used  only  when  there 
is  jto  other  set  of  DS17  data,  i.e.,  no  'nondefault1  0S17  data  for  the 
forms  subpart  and  OHMIS  service  area.  That  is  the  default  DSI7  data  is 
used  only  when  there  is  one  and  only  one  set  of  allowable  limits  for  a 
form  subpart  (or  form)  and  OHMIS  service  area  and  this  set  of  allowable 
limits  applies  in  all  cases.  Unlike  the  DS10  default  data,  the  OS 1 7 
default  data  is  not  used  when  no  match  is  found  to  the  prescribed 
allowable  appl icabil ity  characteristics  data  (DS15  and  DS16);  if  no 
matcn  is  found  between  the  applicability  characteristics  of  the 
allowable  limits  data  being  entered  and  the  prescribed  allowable  limits 
applicability  values,  it  means  that  there  are  rio  allowable  limits 
(i.e.,  values  that  trigger  a  requirement)  which  apply  to  the  forms 
subpart  (or  form)  and  OHMIS  service  area  for  which  the  allowable  limits 
evaluation  is  being  made. 

There  are  several  possible  relationships  between  allowable  limits 
appl icabil ity  factors  and  values  (DS15  and  DS16)  data  and  allowable 
limits  specification  data  (DS17).  For  example,  if  there  was  a  weight 
limit  of  less  than  200  pounds  and  this  applied  regardless  of  what  the 
characteristics  of  the  employee  were,  then  there  would  be  no  DSI5  and 
0S16  data  describing  the  characteristics  the  employee  must  have  (i.e., 
the  applicability  characteristics  and  values)  for  the  weight  limit  to  be 
applied  and  the  program  would  use  the  1  limit  (less  than  200  pounds)  in 
all  cases.  This  limit  would  be  the  default  set  of  DS17  data,  i.e., 
the  set  with  the  form  subpart  identifier  (ID17)  and  the  OHMIS  service 
area  identifier  (ID1Q)  but  no  allowable  limits  application  identifier 
( ID2Q)  for  DS16  data  on  it.  If  the  less  than  200  pounds  limit  applied 
only  to  females,  then  there  would  be  a  set  of  DS15  data  specifying  that 
'sex'  was  a  factor  determining  the  applicability  of  the  limit  and  a  set 
of  DS16  data  specifying  that  the  gender  was  'female',  i.e.,  specifying  a 
value  for  the  applicability  factors;  the  0S17  data  specifying  ‘less  than 
200  pounds'  would  have  the  allowable  limits  application  identifier 
(1020)  for  the  0S16  data  with  the  appl icabil ity  value  of  'female' 
entered  onto  the  DS3.7  data.  If  data  was  entered  for  a  'male',  the 
program  would  then  find  no  DSi6  data  corresponding  to  this  applicability 
cnaracteristic  and  would  thus  "conclude"  that  there  were  no  allowable 
limits  for  this  data  entry;  it  would  not  use  a  default  set  of  DS 17 
data  because  there  would  be  no  default  DS17  data  for  weight  limits 
because  allowable  limits  applicability  factors  and  values  data  (DS15  and 
l)Sib  data)  were  provided.  If  there  was  also  a  weight  limit  of  less  than 


300  pounds  for  'males',  there  would  be  a  second  set  of  DS16  data 
specifying  another  allowable  limit  applicability  value  (males)  and 
another  set  of  0S17  data  with  the  allowable  limit  application  identifier 
(1020)  for  the  second  set  of  DS16  data  on  it  and  with  the  allowable 
limits  specification  of  'less  than  300  pounds'.  Finally,  if  there  were 
no  limits  on  weight  at  all,  there  would  be  no  DS15,  DS15,  or  DS17  data. 
The  default  0S17  data  is  thus  only  used  when  there  is  no  allowable 
limits  applicability  data  (0S15  and  DS16  data)  for  the  forms  subpart 
identifier  (1017)  and  QHMIS  service  area  (ID10). 

As  with  other  0517  data  there  can  be  a  series  of  default  data,  i.e., 
more  than  one  set  of  DS17  data  for  a  given  forms  subpart  and  OHMIS 
service  area.  This  would  be  the  case  if  the  default  DS17  data  had 
multiple  values  and  these  were  specified  as  'logical  ors'  or  there  were 
different  requirements  depending  on  the  degree  to  which  the  value 
entered  on  the  OHMIS  form  was  outside  the  allowable  limit  (e.g.,  a 
different  requirement  if  the  employee  was  between  200  pounds  and  250 
pounds,  than  if  he  was  between  251  and  300  pounds).  There  could  also  be 
multiple  sets  of  DS17  default  data  if  there  were  different  allowable 
limits  specified  for  each  of  the  up  to  6  data  elements  that  made  up  the 
forms  subpart  to  which  allowable  limits  specification  refers. 

As  indicated  above  DS15  data  describes  the  applicability  factors  for 
either  a  forms  subpart  (0S11  data  as  identified  by  a  forms  subpart 
identifier  (ID17))  or  an  entire  form  (DS10  data  as  identified  by  a  forms 
specification  identifier  ( ID16 ) ) .  For  forms  subpart  data,  each  set  of 
DS15  data  provides  up  to  five  applicability  factors  for  the  up  to  6 
forms  units  for  the  forms  subpart  covered  by  the  set  of  DS15  data. 

Forms  units  are  the  identifiers  which  the  data  elements  in  the  forms 
subpart  describe.  For  example,  if  the  data  being  entered  on  the  OHMIS 
form  (i.e.,  the  data  in  the  forms  subpart  being  covered  by  this  set  of 
0S15  data)  was  an  employee's  weight  and  if  the  age  of  the  employee 
determined  the  applicability  of  the  allowable  limit  for  this  data 
element,  the  type  of  forms  unit  described  by  the  forms  subpart  and 
therefore  the  type  of  forms  units  which  the  applicability  characteristic 
(age'  describes  would  be  an  employee.  For  allowable  limits 
applicability  factors  data  (DS15)  covering  allowable  limits  that  apply 
to  the  entry  of  an  entire  class  of  data  (i.e.,  the  allowable  limits  for 
a  form  as  a  whole),  the  DS15  data  identifies  the  up  to  five 
applicability  factors  for  each  of  the  up  9  forms  units  for  the  forms 
specification  data  (DS10)  covered  in  this  set  of  DS15  data. 

1.  Forms  subpart  identifier  ( I  PI  7 )  for  the  group  of  data 
elements  for  which  this  set  of  DS15  data  describes  allowable 
limit  applicability  factors.  This  is  left  blank  if  this  set 
of  DS15  data  describes  allowable  limit  applicability  factors 
for  a  form-as-a-whole . 

2.  Forms  specification  identifier  (ID! 6)  for  the  specification 
of  the  form  for  which  this  set  of  DS15  data  describes  an 
allowable  limit  appl icabi 1 i ty  factor  (for  DS15  data  that  is 
for  a  form-as-a-whole). 
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The  OHMIS  service  identifier  (1D1Q)  for  the  service  area 
specifying  this  data. 

Up  to  five  data  element  type  codes  (CT4)  or  identifier  type 
codes  (CT10)  defining  the  factors  that  determine  the 
applicability  of  an  allowable  limit  for  each  of  the  up  to  6 
forms  units  identified  on  the  forms  subpart  data  (DS10)  (or 
the  up  to  nine  forms  units  on  the  forms  specification  data 
(DS10)  for  0S15  data  applying  to  forms-as-a-whole) .  The  DS11 
data  covered  by  this  set  of  DS15  data  is  identified  by  the 
1017  above  while  the  DS10  data  is  identified  by  the  ID16  given 
above.  Some  forms  units  may  have  no  applicability  factors. 
Many  form  subparts  will  have  less  than  six  (often  only  one) 
forms  unit. 
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Allowable  Limits  Applicability  Values  Data 


This  describes  a  given  set  of  ranges  of  values  that  determine  the 
applicability  of  a  particular  set  (or  a  particular  series  of  sets)  of 
allowable  limits  specifications  data  (DS17)  for  the  data  elements  on  a 
particular  forms  subpart  set  (DS11)  or  a  particular  forms  specification 
(DSlO)  for  a  given  OHMIS  service  area  ( I  DIO ) .  If,  for  example,  a 
particular  set  of  allowable  limits  for  a  value  entered  on  a  physical 
exam  is  to  be  used  only  when  the  employee  is  under  fifty  years  old,  the 

value  'less  than  fifty1  would  be  given  in  the  DS16  data  and  the 

allowable  limits  application  identifier  (ID20)  on  this  set  of  DS16  data 
would  be  entered  on  the  DS17  data  that  is  to  be  used  if  the  prescribed 

allowable  limits  applicability  values  are  met  (i.e.,  in  this  example  if 

the  physical  exam  is  being  given  to  a  person  under  fifty  years  of  age). 
The  DS16  data  may  also  be  used  to  describe  the  applicability  of 
allowable  limits  used  to  describe  an  entire  class  of  data  (i.e., 
allowable  limits  for  forms-as-a-whole)  as  identified  by  a  forms 
specification  identifier  (ID16).  This  use  of  the  DS15  and  DS16  data 
sets  is  described  in  the  forms  specification  data  (DS10)  description. 

The  values  data  given  in  the  DS16  data  corresponds  to  the  forms  unit 
types  specified  in  the  forms  subpart  data  (DS11)  (or  forms 
specif ication  data  (DSlO)  for  applicability  data  for  a  form-as-a-whole) ; 
and,  to  the  allowable  limits  applicability  factors  data  element  types 
specified  in  the  allowable  limits  appl icabil ity  factors  data  (DS15)  for 
the  forms  subpart  identifier  ( 1017 )  (or  forms  specification  identifier 
( ID16 ) )  and  OHMIS  service  area  (ID10)  being  covered  by  the  particular 
set  of  DS16  data.  In  the  sense  the  DS16  data  relates  to  the  DS15  data 
as  the  forms  applicability  values  data  (DS13)  relates  to  the  forms 
applicability  factors  data  (0S12).  However,  because  there  are 
significant  differences  between  the  allowable  limits  specification  data 
(0SI7)  for  which  the  DS16  describes  applicability  and  the  forms 
specification  data  (0S10)  for  which  the  DS13  data  describes 
applicability,  there  are  also  some  differences  between  the  way  that  the 
DS16  data  relates  to  the  DSI7  data  and  the  way  that  the  DSI3  relates  to 
the  DSlO  data. 

The  allowable  limits  specification  data  (DSI7)  is  actually  used  to  show 
ranges  of  values  that  constitute  either  al 1 owable  limits  or 
unallowable  limits.  For  each  set  of  ranges  of  values  given  on  a 
single  set  of  DS17  data  there  is  a  corresponding  set  of  requirements 
description  data  (DS1).  If  the  values  being  entered  on  a  OHMIS  form 
(DS14  data)  match  the  prescribed  range  of  allowable  (or  unallowable) 
limits  given  on  the  DS17  data,  this  triggers  the  generation  of 
requirements  implementation  data  (DS5)  for  the  requirement  corresponding 
to  the  DS 1 7  data.  The  user  may  wish  to  trigger  different  requirements, 
when  the  value  is  outside  the  allowable  limit  (i.e.,  when  it  matches  a 
given  set  of  unallowable  limits)  or  inside  the  allowable  limit  or  the 
user  may  wish  to  have  requirements  triggered  when  a  value  is  either 
outside  an  allowable  limit  or  inside  an  allowable  limit.  Similarly,  the 
degree  to  which  the  value  entered  on  the  OHMIS  form  is  outside  (or 
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inside)  the  allowable  limit  may  determine  which  requirement  is  to  be 
triggered.  Thus,  unlike  the  forms  specification  data  (DS10)  for  a  given 
forms  applicability  values  data  (DS13),  there  may  be  multiple  sets  of 
allowable  limits  specification  data  ( DS 1 7 )  for  a  given  set  of  allowable 
limits  applicability  values  data  (DSlb).  These  multiple  sets  of  DS17 
data  which  are  all  found  to  be  applicable  because  of  a  match  to  a  given 
single  set  of  DS16  data  (i.e.,  which  all  contain  the  same  allowable 
limit  application  identifier  (1020))  are  referred  to  as  an  allowable 
limit  series  (as  distinguished  from  an  allowable  limit  set  which 
identifies  only  one  set  of  0S17  data). 

The  number  of  prescribed  allowable  limits  (or  unallowable  limits)  that 
can  be  given  on  a  single  set  of  DS17  data  depends  on  four  things: 

1)  The  allowable  limits  (or  unallowable  limit)  must  be  only  for 
one  forms  subpart  identifier  (ID17)  (or  forms  specification 
identifier  (ID16)  for  forms-as-a-whole  allowable  limits), 
OHMIS  service  area  ( I  DIO )  and  one  application  of  the  limit 
(i.e.,  one  set  of  DS16  data). 

2)  All  of  the  allowable  (or  unallowable)  limits  on  a  single  set 
of  DS17  data  must  relate  as  ’logical  ands',  not  as  'logical 
ors‘.  For  example,  if  the  allowable  limit  is  that  'A  is  less 
than  X  and  B  is  less  than  Y‘  (where  A  and  B  are  values  for 
data  element  types  that  are  both  on  the  same  forms  subpart), 
then  both  of  these  allowable  limits  must  be  shown  on  the  same 
set  of  0S17  data,  because  they  are  ’logical  ands’  and  both 
allowable  limits  must  be  met  for  the  requirement  specified  in 
the  allowable  limits  specification  data  to  be  triggered.  If, 
on  the  other  hand,  the  allowable  limit  is  that  ’A  is  less 
than  X  or  B  is  less  than  Y’ ,  then  these  two  allowable 
limits  must  be  shown  on  separate  DS17  data  in  order  for  the 
program  to  treat  the  two  limits  as  ’logical  ors’,  i.e.,  to 
trigger  the  requirement  specified  in  the  DS17  data  if  the 
data  entered  on  an  OHMIS  form  is  found  to  match  ei ther 
allowable  limit.  It  is  important  to  note  that  in  this  case 
both  of  these  two  sets  of  DS17  data  could  refer  to  the  same 
set  of  DS16  data  through  the  allowable  limits  application 
identifier  (ID20)),  if  both  limits  are  to  be  used  provided 
the  values  for  the  appl icabi 1 i ty  factors  for  these  limits 
match  those  on  the  0S16  data.  Also  the  two  sets  of  DS17  data 
in  this  series  would  refer  to  the  same  requirement  (i.e., 
contain  the  same  requirement  identifier  (ID6))  because  should 
the  value  entered  on  the  OHMIS  form  match  either  of  these 
allowable  limits  the  same  requirement  is  to  be  triggered. 

3)  All  of  the  allowable  (unallowable)  limits  on  a  single  set  of 
0S17  data  must  trigger  the  same  requirement,  when  the 
values  being  entered  on  the  OHMIS  form  are  found  to  match  the 
allowable  limits  given  on  the  DS 1 7  data.  This  is  because  the 
0S17  data  can  trigger  only  one  requirement.  For  example,  if 
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the  user  wishes  to  specify  that  the  entry  of  a  value  for  a 
data  element  type  on  an  OHMIS  form  that  is  twice  the  base 
line  value  for  that  data  element  type  is  to  trigger  a 
different  requirement  than  the  entry  of  a  value  between  base 
line  and  fifty  percent  above  base  line  for  the  same  data 
element  type,  then  these  two  unallowable  limits  would  be  put 
on  different  sets  of  DS 1 7  data.  Again,  both  of  these  two 
sets  of  DS17  data  could  refer  to  the  same  set  of  DS16  data, 
if  they  were  applicable  under  the  same  circumstances,  and 
therefore  these  two  sets  of  DS17  data  would  be  included  in 
the  same  OS  1 7  data  series  (i.e.,  contain  the  same  allowable 
limit  application  identifier  ( ID20 ) ) . 

4)  The  number  of  allowable  (unallowable)  limits  on  a  given  set 
of  DS17  data  must  fit  the  field  size  of  this  data  set.  This 
field  size  is  explained  below  and  in  the  description  given  of 
the  DS17  data. 

Thus  there  may  be  more  than  one  set  of  DS17  data  for  a  given  set  of  DS16 
data.  There  may  also,  rarely,  be  more  than  one  set  of  DS 16  data  for  a 
given  set  (or  series  of  sets)  of  DS17  data.  If,  for  example,  a  given 
set  of  DS 1 7  data  is  to  be  used  if  'A  or  B  is  true',  then  there  would 
be  two  sets  of  DS16  data  (one  specifying  the  appl icabi 1 i ty  value  'A'  and 
one  specifying  the  applicability  value  ' B 1 )  each  with  a  different 
allowable  limits  application  identifier  (1D20);  there  would  then  be  two 
sets  (or  two  series  of  sets)  of  exactly  the  same  DS17  data,  one  for  each 
set  of  DS16  data,  i.e.,  one  with  each  allowable  limit  application 
identifier  (ID20).  (If  the  set  of  allowable  limits  were  to  be  found 
applicable  if  'A  and  B  were  true',  these  two  applicability  values 
would  be  shown  on  the  same  set  of  DS16  data.) 

Because  it  is  only  rarely  that  there  will  be  more  than  one  set  of  DS16 
data  for  a  given  set  of  DS17  data,  but  the  reverse  will  frequently  be 
true,  the  allowable  limits  specif ication  data  (DS17)  and  applicability 
values  data  (DS16)  are  linked  by  placing  the  allowable  limits 
application  identifier  (ID20)  for  the  DS16  data  on  the  DS17  data,  not 
the  allowable  limits  (ID5;  referred  to  generically  as  the  requirement 
application  identifier  because  it  is  used  for  DS3  and  DS4  data  as  well 
as  0317  data)  from  the  DS17  data  on  the  DS  16  data  as  is  done  for  the 
relationship  between  DS10  and  DS13  data.  This  means  that  in  order  to 
have  two  different  sets  of  DSlb  data  linked  to  the  same  set  of  DS17 
data,  the  0S17  data  must  be  repeated  with  a  different  allowable  limits 
specification  identifier  (ID5)  for  each  of  the  DS16  data  on  each  new  set 
of  DS17  data. 

Of  course,  there  will  in  most  cases,  also  be  more  than  one  set  of  DSI6 
data  for  a  given  forms  subpart  (ID17)  (or  forms  specification  ( ID16 ) ) 
and  OHMIS  service  area  (1010)  each  giving  the  different  circumstances  in 
which  the  same  or  different  allowable  limits  apply  for  the  forms  subpart 
or  forms  specification.  Although  it  is  acceptable  for  two  different 
sets  of  DS16  data  to  be  referred  to  the  same  specifications  for 
allowable  limits  given  in  two  sets  of  DS 1 7  data  and  there  are  to  be  two 
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different  DS17  data  sets  for  the  same  DS16  data,  it  is  important  that 
the  different  sets  of  DS16  data  for  the  same  forms  subpart  (or  forms 
specification)  and  OHMIS  service  area  not  overlap  or  duplicate  each 
other.  For  example,  if  one  set  of  DS16  data  specified  that  the  values 
determining  which  allowable  limits  to  use  were  'greater  than  fifty’  and 
another  set  of  DS16  data  for  the  same  forms  subpart  (i.e.,  the  same  data 
elements)  and  OHMIS  service  area  specified  the  value  'greater  than 
forty’,  then  the  applicability  characteristics  of  the  unit  for  which 
data  was  being  entered  onto  an  OHMIS  form  could  match  more  than  one  set 
of  allowable  limits  applicability  values  data  (DS16  data)  i.e.,  be  both 
greater  than  fifty  and  greater  than  forty  and  this  would  be 
unacceptable.  The  DS16  data  entry  program  (Menu  Selection  4.3.1)  will 
check  for  this  type  of  consistency. 

It  is,  however,  acceptable  for  the  same  set  of  DS16  data  to  specify  the 
applicability  of  overlapping  or  conflicting  allowable  limits.  For 
example,  if  one  set  of  allowable  limits  specification  data  (DS17) 
indicates  that  for  all  ‘females1  (the  DS16  applicability  value)  the 
allowable  (unal lowable)  limit  was  'greater  than  fifty',  while  another 
set  of  DS17  data  for  the  same  application  (i.e.,  for  the  same  DS16 
app 1 icab i 1 i ty  value  for  'females')  indicated  that  the  limit  was  ' greater 
than  forty',  the  allowable  limits  would  overlap.  While  this  may  be 
unnecessarily  redundant,  it  would  not  be  unacceptable.  This  is  because 
the  program  (contained  in  Function  F36)  that  checks  for  whether  the 
values  entered  from  an  OHMIS  form  match  the  allowable  limits  (or 
unallowable  limits)  specified  on  the  DS17  data,  continues  to  check  for 
matches  even  after  a  match  is  found  in  order  that  matches  for  all  of  the 
up  to  six  data  element  types  in  the  forms  subpart  covered  by  a  single 
set  of  DS17  data  may  be  identified.  Therefore,  the  program  will  find 
ail  of  the  Hatches  to  the  overlapping  allowable  limits  values  and 
trigger  the  corresponding  requirement. 

Multiple  sets  of  DS17  data  in  the  same  series  (i.e.,  with  the  same 
allowable  limits  application  identifier  (ID2D))  that  are  inconsistent 
(e.g.,  an  allowable  limit  'equal  to  300’  and  an  allowable  limit  'not 
equal  to  300')  may  be  specified,  because  the  would  be  treated  as 
'logical  ors'  and  there  may  be  different  requirements  triggered  by  these 
two  values.  However,  within  a  single  set  of  DS17  data,  such 
inconsistency  would  be  treated  as  a  'logical  and',  meaning  that  there 
would  be  not  possipility  of  a  match  (i.e.,  no  entry  could  ever  be  'equal 
to  300'  and  'not  equal  to  300').  This  would  not  lead  to  errors  when  the 
program  is  executed,  because,  unlike  the  forms  specification  data  (DS10) 
program  which  would  use  the  default  forms  specif ication  if  no  match  to 
the  forms  app 1 icab i 1 i t y  values  data  (DS13)  vere  found,  it  is  not 
necessary  to  find  a  matching  allowable  limits  specif ication  (DS17)  for 
each  entry  on  an  OHMIS  form.  However,  such  DS17  data  would  be  useless 
and  therefore  the  DS17  data  entry  program  (Menu  Selection  Sequence 
4.1.1)  will  check  for  this  incons istency . 

Tne  user  enters  the  DS16  data  using  Menu  Selection  Sequence  4.3.1. 
Historical  US16  data  is  maintained.  The  DS16  data  may  not  be  changed; 
if  there  is  a  Change  in  the  app! icabi 1 i ty  values  for  an  allowable  limit, 
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the  old  DS16  data  must  be  deactivated  (Menu  Selection  Sequence  4.3.2) 
and  new  DSlb  data  added.  At  the  same  time  the  set  or  series  of  sets  of 
allowable  limits  specif ication  data  (DS17)  with  the  allowable  limits 
application  identifier  (1020)  for  the  set  of  DS16  data  that  has  been 
deactivated  must  also  be  deactivated  and,  if  appropriate,  new  DS17  data 
with  the  same  values  added  with  the  new  ID20  on  it. 

1.  Allowable  limits  application  identifier  (ID20).  Unique 
value  assigned  by  the  program  to  distinguish  this  set  of  DS16 
data. 

2.  Forms  subpart  identifier  ( I Pi 7 )  for  which  this  set  of  DS16 
data  is  specifying  the  values  that  will  be  used  to  determine 
which  allowable  limits  are  applicable.  This  field  may  be 
blank  if  this  DS16  data  specifies  the  applicability  values 
for  a  form-as-a-whole. 

3.  Forms  specification  identifier  ( 1016)  for  the  specif ication 
of  the  form  for  which  this  DS16  data  specifies  applicability 
values  (if  this  DS16  data  is  for  a  form-as-a-whole). 

4.  OHMIS  service  area  identifier  ( I DIO )  for  the  service  area 
specifying  these  applicability  values.  The  combination  of 
the  ID17  (or  1016)  and  I  DIO  given  above  will  determine  which 
set  of  forms  subpart  data  (DS11)  (or  which  set  of  forms 
specification  data  ( DS 10 ) )  and  which  set  of  allowable  limits 
applicability  factors  data  (0S15)  should  be  used  to  determine 
the  identifier  types  (CT10)  and  data  element  types  (CT4)  for 
which  this  0S16  data  is  suppling  the  set  of  applicability 
values . 

5.  The  OHMIS  user  identifier  (ID13)  for  the  person 
promulgating  this  application  of  an  allowable  limit. 

6.  The  employee  identifier  (ID4)  for  the  above  person. 

7.  Date  this  DS16  data  was  generated. 

8.  End  date  (deactivation  date)  for  this  set  of  DS 16  data. 

This  is  the  date  that  this  DS16  data  is  no  longer  active, 
i.e.,  no  longer  to  be  used  on  allowable  limits  specif ication 
data  (DS17)  to  identify  the  allowable  limits  for  which  this 
set  of  DSlb  data  determines  appl i cab i 1 i ty . 

9.  The  range  of  values  (or  identifiers),  if  any,  that  will  be 
used  to  determine  the  applicability  of  the  allowable  limits 
for  each  of  the  up  to  six  forms  unit  types  given  in  the 
DSil  data  corresponding  to  the  forms  subpart  identifier 
(1017)  given  above  (or  for  the  up  to  nine  forms  units  on  the 
forms  specification  data  ( DS 1 J )  corresponding  to  the  forms 
specification  identifier  (11)16)  given  above,  if  this  DS16 
data  is  for  a  form-as-a-whole) .  (See  the  description  given 
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in  the  information  triggered  requirements  applicability  data 
(uS3)  for  how  ranges  of  values  are  specified.) 

l'J.  i 1 1 e  range  of  values  (or  identifiers),  if  any,  that  will  be 

used  to  determine  the  applicable  allowable  limits  for  each  of 
the  up  to  five  data  element  types  given  i n  the  DS15  data 
corresponding  to  the  forms  subpart  identifier  (IDl.7)  (or 
forms  specif ication  identifier  ( 1D16 ) )  and  OHMIS  service  area 
identifier  (ID10)  given  above,  i.e.,  the  data  element  types 
that  define  the  applicability  factors  ( types  of 
characteristics)  for  each  of  the  up  to  six  forms  units  (or  up 
to  nine  forms  units).  There  can  be  as  many  as  five 
applicability  factors  for  each  of  the  up  to  six  forms  units 
(or  up  to  nine  forms  units  for  forms-as-a-whole  applicability 
values),  depending  on  the  definition  of  appl icabil ity  factors 
given  in  the  DS 15  data. 

11.  Description  of  the  conditions  that  must  have  existed  for 

the  above  allowable  limits  applicability  characteristics  to 
nave  been  met  and  the  particular  set  or  series  of  sets  of 
allowable  limits  specifications  data  (DS17)  linked  to  this 
set  of  DS16  to  have  been  used.  This  description  is  used  on 
output  such  as  the  Requirements  Notification  and 
Certification  Record  (03)  to  tell  the  user  why  this  set  of 
allowable  limits  was  used  in  the  allowable  limits  evaluation 
(Function  F38),  i.e.,  why  this  set  of  allowable  limits  was 
determined  to  be  the  applicable  allowable  limit.  This 
description  could  include  a  description  of  those  allowable 
limit  applicability  variables  (i.e.,  forms  units  and 
applicability  characteristics  of  forms  units)  the  values  for 
which  are  to  be  included  in  the  description  of  why  the 
requirement  was  triggered  given  on  the  output.  This 
description  is  to  be  distinguished  from  the  explanation  of 
why  the  requirement  was  triggered  given  on  the  allowable 
limits  specification  data  (0S17).  That  description  explains 
(i.e.,  instructs  the  user  how  to  use  the  information  on  the 
output  to  explain)  why  the  allowable  limits  were  met  (and 
therefore  a  requirement  was  triggered);  this  DS16  explanation 
explains  why  a  particular  set  of  allowable  limits  was  used  to 
evaluate  whether  any  allowable  limits  were  met,  i.e.,  why  a 
particular  set  of  allowable  limits  was  determined  to  be  the 
applicable  allowable  limit. 


a 
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Allowable  Limits  Specification  Data 


This  data  describes  one  set  of  allowable  limits  (or  unallowable  limits) 
information  for  a  set  of  data  elements  in  a  given  forms  subpart  data  set 
(DS11)  (or  forms  specification  data  set  ( DS10 ) )  and  OHMIS  service  area 
(ID10)  and  for  a  given  set  of  allowable  limits  applicability  values  data 
(DS16)  as  identified  by  an  allowable  limits  application  identifier 
(ID20).  This  set  of  "givens"  is  referred  to  hereafter  as  a  "given 
application"  of  an  allowable  limit. 

The  DS17  data  specifies  the  requirement  identifier  (106)  for  the 
requirement  that  is  to  be  triggered  (i.e.,  the  requirement  for  which 
requirements  implementation  data  (DS5)  is  to  be  generated,  should  the 
values  entered  on  the  OHMIS  form  match  the  allowable  (or  unallowable) 
limit  given  on  the  DS17  data.  Specifically  this  data  is  used  to 
generate  the  requirements  implementation  data  (DS5)  that  triggers  a 
requirement.  This  is  done  when  a  value  for  a  data  element  type  that  has 
been  entered  on  a  OHMIS  form  (i.e.,  entered  on  completed  forms  data 
( DS14 ) )  is  found  to  match  the  allowable  limit  (or  unallowable  limit) 
given  on  a  set  of  allowable  limits  specification  data  (DS17)  for  that 
data  element  type.  Requirements  data  is  also  triggered  when  a  user 
enters  data  for  a  certain  type  of  form  (CT9)  for  which  there  are 
allowable  limits  (DS17  data)  and  for  which  the  entry  of  data  from  that 
type  of  form  as  opposed  to  entry  of  data  of  a  given  data  element  type) 
constitutes  matching  an  allowable  limit.  This  type  of  allowable  lv"U 
is  called  an  allowable  limit  for  a  form-as-a-whole  or  an  allowabT  .’it 
for  a  class  of  data  as  opposed  to  an  allowable  limit  for  a  data  c  •:  t 
type  or  form  subpart.  An  example  would  be  an  allowable  limit  for 
number  of  Hazardous  Substance  Incident  Reports  (FT1)  that  can  be  entered 
from  a  given  organizational  unit  before  a  requirement  (e.g.,  a 
requirement  to  determine  why  the  number  of  hazardous  substance  incidents 
is  so  great)  is  triggered. 

The  OS  1 7  data  is  equivalent  to  the  (information  triggered)  requirements 
appl icabil ity  data  (DS3)  that  describes  information  triggered 
requirements  and  to  the  requirements  suspense  data  (DS4)  that  describes 
date  triggered  requirements,  except  that  in  the  case  of  the  DS17  data 
it  is  a  match  to  an  allowable  limit  that  triggers  the  requirement.  The 
requirements  triggered  by  DS17  data  are  referred  to  as  allowable  limits 
triggered  requirements.  This  consistency  with  the  DS3  and  DS4  data  is 
why  the  DS17  data  is  considered  to  be  one  of  the  three  types  of 
requirements  app 1 icab i 1 i ty  data  and  why  each  set  of  DS17  data  (like  each 
set  of  DS3  and  DS4  data)  is  assigned  a  requirements  application 
identifier  (1D5)  to  distinguish  a  unique  set  of  DSI7  data. 

DSI7  data  is  entered  by  the  user  using  Menu  Selection  Sequence  4.1.1. 
Historical  DS17  data  is  maintained.  DS17  data  cannot  be  deleted  or 
changed  (except  for  the  narrative  portions).  If  the  allowable  limit 
does  change,  the  old  DS17  data  is  deactivated  (using  Menu  Selection 
Sequence  4.1.2)  and  new  DS17  data  is  added. 
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There  may  be  more  than  one  set  of  allowable  limits  specifications  data 
for  a  given  application,  i.e.,  with  a  given  allowable  limits  application 
identifier  (ID20).  This  would  be  the  case  if  the  user  wishes  there  to 
be  requirements  triggered  by  both  allowable  limits  and  by  an  unallowable 
limit  for  a  given  data  element  type  and  the  requirements  triggered  in 
these  two  instances  are  to  be  different.  There  may  also  be  different 
sets  of  DS17  data  for  the  same  given  application  if  the  user  wishes  the 
degree  to  which  the  values  for  the  data  entered  on  an  OHMIS  form  are 
outside  (or  inside)  the  allowable  limits  to  affect  what  allowable  limits 
requirements  are  to  be  triggered.  The  multiple  sets  of  DS17  data  for 
the  same  application  (1020)  are  referred  to  as  a  series  of  sets  of 
DS17  data  or  an  allowable  limits  specification  series. 

Each  set  of  forms  subpart  data  (DS11)  on  a  form  (ID18)  or  each  form  type 
(CT9)  may  have: 

1)  no  OS 1 7  data,  if  there  are  now  allowable  limits  for  the  forms 
subpart  or  form  type;  or, 

2)  multiple  sets  or  multiple  series  of  sets  of  DS17  data,  if 
different  allowable  limits  apply  depending  on  the 
applicability  values  for  the  data  entered  (e.g.,  one  set  of 
allowable  limits  for  females  and  another  set  of  allowable 

1 imits  for  males) ;  or, 

3)  only  one  set  or  one  series  of  sets  of  DS17  data  that  does 
not  link  to  any  particular  allowable  limits  applicability 
data  (i.e.,  has  no  ID20  on  the  DS17  data  and  therefore  does 
not  refer  to  any  0S16  data).  This  last  kind  of  DS17  data  is 
called  the  ' default1  allowable  limit  for  the  form  subpart 
(or  form-as-a-whole)/service  area  and  is  used  when  there  are 
no  factors  that  determine  the  applicability  of  an  allowable 
limit,  i.e.,  no  DS15  or  DS16  data  for  the  forms  subpart  (or 
form-as-a-whol e)  and  service  area.  If  there  are  allowable 
limits  applicability  factors  and  values  (DS15  and  DS16  data), 
but  none  of  the  prescribed  applicability  values  match  those 
values  for  the  data  being  entered,  then  the  default  DS17 
data  is  not  used.  Instead,  this  finding  indicates  that 
there  is  no  allowable  limit  applicable  for  the  data  being 
entered.  (If  there  are  no  allowable  limits  at  all,  there 
would  be  no  DS17  data,  of  any  kind,  including  a  default  DS17 
data. ) 

For  each  set  of  DS17  data  there  must  be  one  set  of  requirements 
description  data  (DS1)  for  the  requirement  that  is  to  be  triggered  if 
the  values  entered  on  an  OHMIS  form  (or  the  frequency  of  the  entry  of 
the  form-as-a-whole)  are  found  to  match  the  allowable  (or  unallowable) 
limits  given  on  the  DS17  data.  This  set  of  DS1  data  is  identified  by 
placing  the  requirement  identifier  (ID6)  distinguishing  the  DS1  data  on 
the  DSI7  data.  If  there  is  more  than  one  requirement  for  a  given  set  of 
allowable  limits  (or  unallowable  limits)  data,  a  separate  set  of  DS17 
data  with  the  same  values,  but  a  different  ID6  on  it,  must  be  generated. 
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The  ID6  specifies  the  requirement  which  is  to  be  triggered  (i.e.,  the 
requirement  for  which  requirements  implementation  data  (DS5)  will  be 
generated),  when  the  value  entered  on  an  OHMIS  form  (or  the  frequency  of 
the  entry  of  a  form-as-a-whole)  matches  the  allowable  limits  or 
(unallowable  limits)  given  on  the  DS17  data. 

The  user  may  wish  to  specify  that  a  different  requirement  be  triggered 
for  different  degrees  of  being  outside  the  allowable  limit.  For 
example,  the  user  may  wish  that  a  different  action  (requirement)  be 
taken,  if  the  value  is  twice  the  allowable  limit  than  he/she  would  have 
if  the  value  were  only  fifty  percent  over  the  allowable  limit.  If  the 
user  wishes  different  requirement  to  be  triggered  for  different 
allowable  (unallowable)  limit  values,  this  must  be  given  by  specifying 
multiple  sets  of  DS17  data  and  linking  the  requirements  description  data 
(DS1)  to  the  DS17  data  through  a  different  requirement  identifier  (ID6) 
on  each  set  of  DS17  data.  If  there  is  multiple  DS17  data  of  this  type 
(i.e.,  all  of  which  have  the  same  application  such  as,  in  the  above 
example,  having  both  of  the  two  allowable  limits  apply  only  to 
■females'),  this  is  shown  by  giving  the  same  allowable  limits 
application  identifier  (1020)  on  each  set  of  DS17  data. 

In  addition  to  being  multiple  sets  of  DS17  data  because  different 
requirements  are  to  be  triggered,  there  may  be  multiple  DS17  data 
because  there  is  more  than  one  allowable  limit  and  these  multiple  limits 
are  not  continuous  and  cannot  therefore  be  expressed  in  a  single  range 
of  values.  An  example  would  be  an  allowable  limit  of  '10'  £r  '40'. 

Finally,  in  addition  to  triggering  one  or  more  requirements  because  a 
value  is  outside  an  allowable  limit,  the  user  may  wish  to  specify 
certain  requirements  associated  with  being  within  an  allowable  limit. 

For  example,  the  user  may  wish  medical  surveillance  terminated  if  the 
value  for  a  medical  finding  is  within  a  certain  allowable  limit. 
Requirements  that  are  triggered  by  values  that  are  within  an  allowable 
limit  are  specified  by  the  user  in  the  same  way  as  requirements  that  are 
triggered  by  being  outside  an  allowable  limit.  Again,  the  requirements 
for  allowable  limits  that  are  within  an  allowable  limit  may  depend  on 
the  degree  to  which  the  value  entered  on  the  OHMIS  form  is  with  the 
allowable  limit,  in  which  case,  there  would  be  multiple  sets  of  DS17 
data,  each  specifying  a  different  range  of  values  that  are  within  the 
allowable  limit,  thus  enabling  different  sets  of  requirements  to  be 
linked  to  these  different  values.  In  this  sense,  the  entry  of  any 
completed  forms  data  (DS14)  for  which  there  are  allowable  limits 
constitutes  a  triggering  step  as  defined  in  the  requirements  Function, 
(i.e.,  F2).  That  is,  the  entry  of  DS14  data  triggers  a  check  to 
determine  if  there  are  applicable  requirements,  except  that  in  this  case 
the  applicability  of  a  requirement  depends  on  whether  the  value  entered 
on  the  form  matches  and  allowable  (unallowable)  limit. 

If  should  be  emphasized  that  a  set  of  DS17  data  should  be  added  to  the 
OHMIS  data  base  if  and  only  if  a  requirement  is  to  be  triggered  whenever 
tne  values  entered  on  the  OHMIS  form  match  the  limits  given  on  the  DS17 
data.  If  no  action  is  to  be  taken  when  there  is  a  given  single  range 


DATA  SET  17 


of  values  entered,  then  no  DS17  data  should  be  specified.  This  is  why 
the  DS17  data  will  frequently  specify  unal lowable  (rather  than 
allowable)  limits:  It  is  often  the  case  that  it  is  the  unallowable 
limits  that  trigger  an  action.  (However,  a  requirement  may  be  triggered 
by  either  or  both  allowable  limits  and  unallowable  limits.)  Caution 
must,  therefore,  be  taken  in  specifying  the  values  for  the  limits  in  the 
0S17  data  to  ensure  that  the  intended  relationship  between  the  limit  and 
the  requirement  is  given.  For  example,  supposing  the  al lowable  limits 
for  a  particular  data  element  type  on  a  forms  subpart  were  either  '10' 
or  '40'  and  that  if  either  allowable  limit  were  met,  no  requirement 
was  to  be  triggered,  i.e.,  there  were  requirements  only  if  the  values 
entered  on  the  OriMIS  form  were  outside  the  two  allowable  limits  (not 
'10'  and  not  '40').  The  user  would  then  wish  to  specify  this  allowable 
limit  as  an  unal lowable  limit,  i.e.,  if  the  value  entered  on  the  OHMIS 
form  was  not  equal  to  '10‘  and  not  equal  to  ' 40 1  ,  then  the  requirement 
should  be  triggered.  Note  that  the  unallowable  limit  is  an  ‘logical 
and',  while  the  allowable  limit  ('10‘  £r  ‘40')  was  a  'logical  or1, 
and  therefore  the  unallowable  limit  should  be  entered  on  a  single  DS17 
data  set.  If  the  two  unal lowable  limits  were  listed  on  separate 
DSI7  data  (i.e.,  treated  as  'logical  ors 1 ) ,  the  program  would 
necessarily  always  trigger  at  least  one  of  the  two  requirements  on  the 
two  sets  of  DS17  data.  This  is  because  the  value  entered  on  the  form 
could  never  be  both  '10'  and  ’40’,  so  that  it  would  match  at  least  one 
of  the  unallowable  limits  specified  (i.e.,  it  would  either  match  the 
‘not  equal  to  10'  or  match  the  'not  equal  to  40'  or  both)  and  a 
requirement  would  thus  be  triggered  in  every  case.  This  would  not  be 
the  relationship  between  the  allowable  limit  and  the  requirement  that 
the  user  intended.  This  is  an  example  of  how  allowable  and  unallowable 
limits  must  be  specified  carefully  in  order  to  trigger  the  desired 
requirement. 

A  single  set  of  OS 1 7  data  can  include  up  to  twelve  allowable  (or 
unallowable)  limit  specifications,  covering  one  or  more  of  the  up  to  six 
data  element  types  (CT4)  that  make  up  the  forms  subpart  data  ( OS 11) 
covered  by  the  DSI7  data  (for  DS17  data  that  covers  forms  subparts, 
i.e.,  data  element  types,  as  opposed  to  forms-as-a-whole) .  All  of  the 
data  on  a  single  DS17  data  set  will  be  treated  as  'logical  ands',  i.e., 
the  values  entered  for  the  forms  subpart  onto  the  OHMIS  form  must  match 
all  of  the  up  to  twelve  allowable  limits  on  the  DS17  data  set  for  it  to 
be  considered  a  'match'  and  the  requirement  implementation  data  (0S5) 
for  the  requirement  triggered  by  the  allowable  limit  to  be  generated. 

Allowable  Limits  Data  Elements 


To  enter  one  of  the  up  to  twelve  allowable  limits  specifications  on  the 
DS17  data  set  the  following  set  of  five  data  elements  (referred  to  as 
"Allowable  Limits  Data  Elements")  must  be  completed: 

1 )  A  number  from  I  to  6  indicating  for  which  of  the  up  to  six 
data  element  types  for  a  forms  subpart  covered  by  this  DSl7 
allowable  limits  data  is  being  specified"!  The  DS 1 7  data 
entry  program  (Menu  Selections  Sequence  4.1.1)  will  check  that 
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the  number  entered  is  consistent  with  the  number  of  data 
element  types  on  the  forms  subpart  being  covered  by  this  set 
of  DS17  data  as  determined  from  the  forms  subpart  data  (DS11). 

2)  A  range  of  values  for  the  allowable  limit.  This  range  of 
values  may  be  given  in  the  form  of  a  table  (allowable  limit 
table  data  (DS21)),  by  giving  an  allowable  limit  table 
identifier  (ID25)  or  the  values  can  be  given  here  as  a  range 
using  the  following  format.  A  range  is  specified  using  one  of 
up  to  ten  formats:  The  allowable  limit  (or  unallowable  limit) 
must  have  a  value  that  is  a)  equal  to  or  b)  not  equal  to,  the 


owing 

five  subformats: 

i) 

X 

ii) 

>  X 

iii) 

<  X 

iv) 

>  X  and  <  Y 

V) 

<  X  and  >  Y 

In  this  range  of  values  X  or  Y  may  be  one  of  the  following  six 
types  of  values: 

i)  Any  individual  value,  e.g.  '1C 

ii)  The  original  base  line  value  for  the  data 
element  type.  The  base  line  value  is  the  first 
value  ever  entered  onto  the  OHMIS  data  base  of 
a  given  data  element  type  for  a  given  forms 
unit. 

iii)  The  latest  secondary  base  1 ine  value  for  the 
data  element  type.  The  'secondary  base  line' 
is  a  value  that  is  not  an  original  base  line, 
but  has  been  designated  as  a  "new"  base  line. 

A  secondary  base  line  might  be  used,  for 
example,  if  an  employee  is  rehired  after  a  long 
stay  away  from  the  Department  of  the  Army. 
Secondary  base  lines  are  identified  by  the  user 
on  the  completed  forms  data  (DS14). 

iv)  Number  from  1  to  6  of  the  up  to  five  other 
data  element  types  in  the  forms  sub  part  being 
covered  by  this  set  of  DS17  data. 

v)  The  original  base  line  for  one  of  the  up  to 
five  data  element  types  in  this  form  subpart. 

vi)  The  secondary  base  1 ine  for  one  of  the  up  to 
five  data  element  types  in  this  form  subpart. 

Some  examples  of  how  these  formats  can  be  used  to  specify 
allowable  limits  or  unallowable  limits  would  be  that  the 
allowable  limit  is:  Equal  to  10;  not  equal  to  10;  not  equal 
to  between  10  and  40;  not  equal  to  the  original  base  line  for 
this  data  element  type;  greater  than  the  value  for  a  specified 
other  data  element  type  in  this  forms  subpart;  greater  than 
the  secondary  base  line  for  one  of  the  up  to  five  other  data 
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element  types;  less  than  the  base  line  for  this  data  element 
type  or  greater  than  14;  etc.  For  the  allowable  limits  values 
using  base  line  or  other  data  element  types,  the  user  simply 
enters  a  code  meaning  base  line  (original  or  secondary)  and/or 
a  number  from  1  to  6  meaning  the  number  of  the  other  data 
element  type  on  this  forms  subpart.  The  program  will 
look  for  these  values  and  capture  them  from  the  OHMIS  data 
base  when  evaluating  allowable  limits  (in  Function  F3B).  If 
they  are  inconsistent,  e.g.,  the  allowable  limit  is  '>30  and  < 
base  line1  and  the  actual  value  for  the  base  line  is  1 25 ‘ ,  the 
program  will  treat  the  allowable  limits  evaluation  as  though 
it  were  a  manual  allowable  limits  evaluation  and  require  the 
user  to  conduct  a  manual  allowable  limits  evaluation  using  the 
allowable  limits  check  function  (Function  F3C). 

3)  The  relationship,  if  any,  of  the  above  range  of  values  to 

the  other  values.  That  is  the  relationship  between  the  data 
element  type  given  in  Allowable  Limits  Data  Element  Part  1  and 
the  other  data  element  types  in  the  forms  subpart.  This 
information  is  specified  using  the  following  three  subdata 
elements : 

3a)  For  which  of  the  other  values  is  the  relationship 
being  defined? 

i)  The  original  base  line  value  for  the  data 
element  type. 

ii)  The  latest  secondary  value  for  the  data  element 
type. 

iii)  Number  from  I  to  6  of  the  up  to  five  data 
element  types  in  the  forms  subpart  covered  by 
this  DS17  data. 

iv)  The  original  base  line  for  one  of  the  up  to 
five  other  data  element  types  in  the  forms 
subpart . 

v)  The  secondary  baseline  for  one  of  the  up  to 
five  other  data  element  types. 

3b)  Whether  the  relationship  is  multipl icative  or 
additive.  The  format  for  multiplicative 
relationships  would  be  that  the  allowable  limit  for 
the  value  of  the  data  element  type  specified  in 
Allowable  Limits  Data  Element  Part  1  above  must  be 
1 X *  times  (  >  or  <  )  the  value  of  the  data  element 
type  specified  in  Allowable  Limit  Data  Element  Part 
3a  above,  where  ’X1  is  the  range  of  values  entered 
in  Allowable  Limit  Data  Element  Part  2  above.  An 
additive  relationship  would  be  that  the  data  element 
specified  in  Allowable  Limit  Data  Element  Part  1 
must  match  what  the  value  of  the  data  element  type 
specified  in  Allowable  Limit  Data  Element  Part  3a 
would  be  if  'X*  were  added  to  (or  subtracted 
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from)  that  data  element  type,  where  'X1  is,  again, 
the  value  entered  in  Allowable  Limit  Data  Element 
Part  2. 

3c)  Whether  the  relationship  is  greater  than  or  less 

than  (for  multiplicative  relationships);  whether  the 
relationship  is  added  to  £r  subtracted  from  (for 
additive  relationships). 

Examples  of  allowable  limits  using  the  three  data  element 
types  in  this  format  would  be  to  specify  that  the  data  element 
type  specified  in  Allowable  Limit  Data  Element  Part  1  must  be: 
equal  to  (or  not  equal  to)  ID  times  greater  than  or  less  than) 
the  original  base  line  for  this  data  element  type;  less  than 
10  times  less  than  the  base  line  for  this  data  element  type; 
one  third  of  the  base  line  for  the  other  data  element  types 
specified  in  Allowable  Limit  Data  Element  Part  3a;  not  equal 
to  10  more  than  (added  to)  or  less  than  (subtracted  from)  the 
secondary  base  line  for  this  data  element  type;  not  equal  to 
between  10  and  40  subtracted  from  (or  added  to)  the  value  from 
another  data  element  type;  not  equal  to  the  original  base  line 
for  this  data  element  type  added  to  the  value  of  another  data 
element  type;  greater  than  (or  less  than)  the  product  (or  sum 
or  remainer)  resulting  when  the  value  specified  for  another 
data  element  type  given  in  Allowable  Limit  Data  Element  Part  2 
above  is  multiplied  (divided,  added  or  subtracted)  from  the 
data  element  type  given  in  Allowable  Limit  Data  Element  Part 
3a  above;  etc. 

4)  Whether  or  not  the  above  specified  allowable  limit  is  to  be: 

i)  Cumulative  for  the  time  span  shown  in  Allowable 
Limit  Data  Element  Part  5  below;  or 

ii)  true  for  each  data  entry  made  during  the  time  span 
shown  in  Allowable  Limit  Data  Element  Part  5  below. 

5)  The  time  span  shown  for  the  allowable  limit.  This 
information  consists  of  the  following  two  data  elements: 

5a)  A  range  of  values  for  the  time  span.  As  time  can 
only  be  a  positive  number  this  range  of  values  must 
be  equal  to  or  greater  than  1. 

5b)  Whether  the  time  span  specified  in  Allowable  Limit 
Data  Element  Part  5a  above  is  for: 

i)  The  number  of  data  entries  of  the  data 

element  type  specified  in  Allowable  Limit  Data 
Element  Part  1  above  for  the  value  of  the  forms 
units  specified  on  the  completed  forms  data 
(DS14  data)  ’•here  are  applicable  to  this  data 
element  type. 


1 
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ii)  A  given  unit  of  time  and  if  so  what  unit. 

Units  of  time  can  be  days,  months,  years,  etc; 
they  could  also  be  seconds,  minutes,  hours, 
etc,  if  the  time  (as  well  as  the  date)  that 
the  value  for  the  data  element  type  specified 
in  Allowable  Limit  Data  Element  Part  1  above 
was  obtained  is  entered  on  the  completed  forms 
data  (DS14). 

iii)  A  time  period,  e.g.,  a  week,  month,  quarter, 
etc.  and  if  so  the  time  period  identifier 
(1024)  identifying  the  time  period 
specification  data  (DS20)  for  which  the  time 
span  values  given  in  Allowable  Limit  Data 
Element  Part  5a  above  apply. 

This  time  span  information  given  in  Allowable  Limit  Data 
Element  Part  5  enables  the  user  to  specify  the  following  two 
types  of  allowable  limits: 

o  Cumulative  (answer  of  ‘i1)  in  Allowable  Limit  Data 
Element  Part  4  above:  To  be  considered  a  match 
with  the  allowable  limit,  the  sum  of  all  of  the 
values  of  the  data  entries  for  a  given  form  unit(s) 
made  during  the  time  span  shown  by  the  values  given 
in  Allowable  Limits  Data  Element  Part  5  above  must 
be  equal  to  the  allowable  limit  given  in  Allowable 
Limit  Data  Element  Part  2  or  Allowable  Limit  Data 
Element  Part  3  above. 

o  Noncumul ative  (answer  of  'ii')  in  Allowable  Limit 
Data  Element  Part  4  above:  To  be  considered  to  be 
a  match  with  the  allowable  limit,  each  of  the 
values  of  the  data  entry  made  over  the  time  span 
shown  by  the  values  entered  in  Allowable  Limit  Data 
Element  Part  5  above  for  the  data  element  type 
specified  in  Allowable  Limit  Data  Element  Part  1 
above  for  a  given  form  unit(s),  must  be  equal  to  the 
allowable  limit  given  in  Allowable  Limit  Data 
Element  Part  2  or  Allowable  Limit  Data  Element  Part 
3  above. 

In  these  two  types  of  formats  for  providing  time  span 
information  the  allowable  limit  time  span  can  be  defined  in 
three  ways : 

o  The  amount  of  time  it  has  taken  to  make  'X'  number 
of  entries  (answer  of  5,  b,  i) 

o  'X'  amount  of  time  units  (i.e.,  days,  months,  years, 
etc.  (answer  5,  b,  ii )) ;  or 

o  'X'  amount  of  time  period  (answer  5,  b,  iii). 


DATA  SET  17 


Where  'X'  in  all  three  cases  is  the  value  entered  in  Allowable 
Limit  Data  Element  Part  Sa.  Time  units  are  distinguished  from 
time  periods  in  the  following  way: 

o  Time  units  end  on  the  date  that  the  value  for  the 
data  element  type  was  obtained  as  shown  from  the 
completed  forms  data  (DS14),  i.e.,  the  date  used 
when  making  the  evaluation  of  allowable  limits. 

Time  units  begin  on  the  date  equal  to  the  end  date 
minus  the  time  span  shown  by  the  value  in  Allowable 
Limit  Data  Element  Part  5a. 

o  T ime  periods  end  on  the  same  date  as  time  units, 
but  begin  on  a  specified  date. 

For  example,  a  time  span  of  90  days  (90  time  units  where  the 
unit  is  'days')  would  begin  90  days  before  the  value  for  the 
data  element  was  obtained.  A  time  span  of  one  quarter  (1 
time  period  where  the  period  is  'quarter'),  would  begin  on 
the  last  date  that  the  quarter  during  which  the  value  for  the 
data  element  was  obtained  began,  e.g.,  March  1,  which  might  be 
considerably  less  than  90  days  prior  to  the  date  that  the  data 
was  obtained.  Being  able  to  specify  either  a  time  unit  or  a 
time  period  enables  the  time  span  for  allowable  limits  to  be 
given  as  either  having  a  match  during  the  last  unit  of  time 
equal  to  a  quarter  (90  days)  or  as  having  a  match  since  the 
beginning  of  the  current  time  period  equal  to  a  quarter.  If 
the  user  wishes  to  state  that  the  allowable  limit  criteria  is 
that  value  'X'  cannot  have  been  entered  more  than  once  during 
the  last  90  days,  he  would  use  time  units  to  specify  a  time 
span;  if  the  user  wishes  to  specify  that  the  allowable  limit 
criteria  is  that  value  'X'  cannot  have  been  entered  more  than 
once  since  the  beginning  of  the  current  quarter,  he  would  use 
time  periods.  The  beginning  dates  for  the  time  periods  are 
defined  in  the  time  period  specification  data  (DS20). 

Examples  of  these  types  of  time  span  specifications  about 
allowable  limits  would  include  specifying: 

o  An  example  of  a  cumulative  time  span  specification 
(i.e.,  an  answer  of  'i)1  in  Allowable  Limit  Data 
E 1 ement  Part  4:  To  be  considered  to  match  the 
allowable  limit  the  sum  of  a  given  employees 
millirems  of  radiation  exposure  over  a  time  period 
of  one  calendar  quarter  (i.e.,  since  the  beginning 
of  the  current  calendar  quarter)  must  be  less  than 
18,750  millirems.  In  this  example: 


Millirems  of  radiation  of  exposure  is  the  data 
element  type  entered  onto  the  OHMIS  form  for 
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which  this  set  of  DS17  data  is  providing 
allowable  limits  specifications,  i.e.,  the 
Allowable  Limit  Data  Element  Part  1; 

The  time  span  specified  was  one  calendar 
quarter.  This  was  specified  by  answering 
Allowable  Limit  Data  Element  Part  5a  with  the 
value  *1’  and  Allowable  Limit  Data  Element  Part 
5b  with  the  value  ’  i  i  i )  *  (time  period)  and  the 
time  period  specification  identifier  (1024)  for 
a  calendar  quarter; 

The  value  18,750  is  the  allowable  limit 
specified  in  Allowable  Limit  Data  Element  Part 

2. 

o  An  example  of  a  noncumulative  (i.e.,  answer  of 

‘ i i ) 1 )  in  Allowable  Limit  Data  Element  Part  4:  To 
be  considered  to  match  the  allowable  limit,  each 
of  the  radiation  exposure  entries  made  for  a  given 
employee  for  the  last  two  entries  (for  two  entries 
in  a  row)  must  be  greater  than  1,000  millirems.  In 
this  example: 

The  user  specified  the  time  span  as  follows: 

+  The  value  of  Allowable  Limit  Data  Element 
Part  5a  was  given  as  '2'  and 

+  The  value  given  for  Allowable  Limit  Data 
Element  Part  5b  was  * i ) *  (number  of  data 
entries ) ; 

'1000'  is  the  unallowable  limit  specified  in 
Allowable  Limit  Data  Element  Part  2. 

o  Another  cumulative  example:  To  be  considered  a 
match  to  tne  allowable  limit,  the  sum  of  the 
radiation  exposure  entries  made  for  a  given  employee 
over  the  last  90  days  must  be  greater  than  1000 
millirems.  In  this  example  the  user  specified  the 
time  span  as  follows: 

The  value  for  Allowable  Limit  Data  Element  Part 
5a  was  given  as  1 90'  ;  and, 

the  value  for  Allowable  Limit  Data  Element  Part 
5b  was  specified  as  1  i  i ) 1  (time  unit)  with  the 
unit  specified  as  'days'. 


o 


Another  noncumulative  example:  To  be  considered  a 
match  to  the  allowable  limit,  the  value  for  each 
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entry  of  millirems  entered  on  an  employee  must  be 
greater  than  1,000  millirems.  In  this  example  there 
is  no  time  span;  the  allowable  limit  (1,000 
millirems)  is  given  in  Allowable  Limit  Data  Element 
Part  2  and  applies  regardless  of  the  results  of  the 
previous  entries  of  millirems  values  for  the  same 
employee  (i.e.,  previous  entries  of  the  same  data 
element  type  for  the  same  f: rms  unit).  In  this 
example  Allowable  Limit  Data  Element  Part  5a  would 
be  answered  as  and.  Allowable  Limit  Data 

Element  Part  5b  would  be  answered  as  'i)‘  (number  of 
data  entries). 

It  should  be  noted  that  the  time  span  information  part  of  the 
allowable  limits  specifications  makes  it  important  to  keep 
track  of  the  sequence  in  which  a  given  data  element  type  for 
a  given  forms  unit  is  entered.  For  example,  if  an  allowable 
limit  specification  is  of  the  format  "the  test  result  A  must 
have  been  greater  than  X  for  the  last  10  times  that  this  test 
result  was  entered  for  this  employee",  then  it  is  important 
that  the  program  be  able  to  quickly  identify  the  sequence  in 
which  the  test  result  A  values  were  entered  for  an  employee. 
This  is  made  more  difficult  by  the  fact  that  the  form  used  to 
enter  a  certain  type  of  test  result  (or  other  data  element 
type)  may  change  over  time  and  the  fact  that  in  some  cases  not 
all  of  the  data  on  a  form  will  be  completed.  These  two  facts 
mean  that  it  is  not  possible  to  identify  the  sequence  of  an 
entry  of  a  data  element  type  for  a  given  forms  unit  simply  by 
counting  the  number  of  forms  entered  for  a  forms  unit  of  the 
form  type  on  which  the  data  element  type  is  entered.  Instead, 
each  value  entered  for  a  given  data  element  type  must  be  given 
a  Data  Element  Sequence  Number.  This  sequence  number  is 
identified  for  a  value  of  a  data  element  type  by  the  OHMIS 
program  (not  the  user)  by  using  the  current  forms  list  (DL?3) 
to  identify  the  last  set  of  completed  forms  data  ( DS 14 )  for 
the  same  type  of  form  (CT9)  that  has  a  completed  entry  for  the 
data  element  type.  This  Data  Element  Sequence  Number  is 
entered  onto  the  DS14  data  at  the  time  that  the  values  from  an 
OHMIS  form  are  entered  onto  the  OHMIS  data  base  (Function 
F 38) . 

As  can  be  seen  from  the  above  examples,  a  very  wide  range  of  types  of 
allowable  limits  can  be  specified  using  the  DS17  data.  Another  example 
must  be  given  however  to  indicate  how  the  user  may  specify  table-type 
allowable  limits.  Often  allowable  limits  are  of  the  type  "if  the  value 
for  A  is  X,  then  the  value  for  B  must  be  Y".  For  example,  an  allowable 
limit  such  as  the  airflow  required  for  a  hood  (value  for  ’A')  often 
depends  on  the  amount  of  the  hazardous  substance  (value  for  ' B’ )  being 
used  within  the  hood.  This  type  of  allowable  limit  is  basically  similar 
to  a  'logical  and'  type  of  allowable  limit  and  could  be  shown  in  the 
same  way  as  the  allowable  limits  in  the  other  examples  given  above,  by 


generating  multiple  sets  of  0S17  data  each  with  a  pair  (in  this  case) 
of  allowable  limits  (one  for  'A'  and  one  for  ' B * )  on  a  single  DS17 
data  set.  However,  this  would  be  cumbersome  as  there  may  be  a  very  long 
number  of  pairs  (or  more  in  other  examples  of  this  type  of  allowable 
limits  specification)  of  values  needed,  i.e.,  a  very  large  table. 

To  avoid  this,  another  allowable  limit  format  can  be  used.  In  this 
format,  the  user  would  complete  one  set  of  DS17  data  specifying  the 
relationship  between  the  up  to  six  data  element  types  in  the  forms 
subpart  covered  by  the  DS17  data.  However,  no  values  for  the  allowable 
limit,  i.e.,  no  Allowable  Limit  Data  Element  Part  2  of  the  above  five 
allowable  limit  data  elements,  would  be  giver  in  the  DS 1 7  data.  Instead 
the  user  would  enter  an  allowable  limit  table  identifier  (1D25)  on  the 
DS17  data  identifying  the  series  of  allowable  limit  tables  data  sets 
(DS21),  i.e.,  the  allowable  limits  table  containing  the  allowable  limits 
table  list  (DL19).  Each  0S21  data  set  provides  one  of  the 
combinations  of  the  values  for  the  up  to  six  data  element  types  on  a 
forms  subpart  that  are  to  constitute  a  match  to  an  allowable  (or 
unallowable)  limit  and  thus  trigger  the  requirement  specified  in  the 
0S17  data.  The  DL19  lists  all  of  the  DS21  data  for  a  given  1025,  i.e., 
all  0S21  data  sets  in  the  same  table. 

The  allowable  limits  specification  data  ( DS 17)  is  also  used  for  an 
allowable  limit  covering  an  entire  class  of  data,  i.e.,  the  entry  of 
data  for  a  'form-as-a-whole*.  (This  type  of  allowable  limit  is 
described  in  the  form  specification  data  ( DS 10 ) ) .  Basically,  this  type 
of  allowable  limit  would  specify  the  number  of  entries  of  data  for  a 
certain  type  of  form  (rather  than  for  a  certain  data  element  type)  for  a 
given  forms  unit  needed  to  be  considered  a  match  to  an  allowable  limit. 
An  example  of  such  an  allowable  limit  would  be  "if  X  Hazardous  Substance 
Incident  Reports  (FT1)  were  entered  for  a  given  facility  within  a  given 
month"  the  allowable  limit  would  have  been  met  and  a  requirement  would 
be  triggered.  In  this  example,  'X'  is  the  allowable  limit,  the 
'facility'  is  the  forms  unit  and  the  'month'  is  the  time  spanned. 

The  major  difference  between  allowable  limits  for  data  element  types 
(which  are  covered  by  forms  subparts)  and  allowable  limits  for 
forms-as-a-whole  are  that  the  DS17  data  applies  to  a  forms  specification 
identifier  ( 1016)  rather  than  a  forms  subpart  identifier  (ID17).  Also 
the  number  of  data  element  types  that  can  be  forms  units  is  9,  rather 
than  6  (it  is  very  unlikely  that  nine  will  ever  be  used,  but  the 
identification  of  the  data  element  types  that  constitutes  the  forms 
units  is  based  on  the  order  in  which  the  forms-as-a-whole  forms  units 
are  listed  as  identified  in  the  DS10  data;  as  there  can  be  9  such  forms 
units  on  a  given  form,  the  number  needed  to  cover  all  of  the  different 
forms  subparts  that  may  be  on  a  form),  the  value(s)  identifying  the 
forms  unit(s)  for  the  form-as -a-whol e  can  be  from  1  to  9.  Another 
difference  between  data  element  type  and  form-as-a-whole  types  of 
allowable  limits  is  that  there  can  be  no  'logical  ands'  in  the  allowable 
limits  specification  for  forms-as-a-whole;  that  is;  only  one  of  the  up 
to  12  sets  of  Allowable  Limit  Data  Element  sets  can  be  completed  on  a 
given  set  of  DS 1 7  data  for  this  type  of  allowable  limits  spec i f i cat  ion . 
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Specific  other  differences  in  completing  the  5  Allowable  Limit  Data 
Element  Parts  for  the  form-as-a-whole  type  of  allowable  limit  are: 

o  The  value  for  the  data  element  type  identified  as  Allowable 
Limit  Data  Element  Part  1  is  left  blank. 

o  The  allowable  limit  given  (i.e.,  the  value  given  in  Allowable 
Limit  Data  Element  Part  2  must  always  be  a  positive  number). 
Also,  it  cannot  be  an  allowable  limit  table  identifier  (ID25), 
another  data  element  type,  a  base  line,  etc. 

o  There  would  be  no  relationship  to  other  data  element  types  or 
base  line  data,  i.e.,  the  Allowable  Limit  Data  Element  Part  3 
would  be  left  blank. 

o  The  answer  to  Allowable  Limit  Data  Element  Part  4  would  always 
be  'cumulative'.  (Note:  If  entry  of  data  for  this  type  of 
form-as-a-whole  only  once  constitutes  the  allowable  limit 
trigger,  the  value  for  Allowable  Limit  Data  Element  Part  4 
would  still  be  'cumulative',  but  the  value  for  Allowable  Limit 
Data  Element  Part  5a  would  be  '1'). 

o  The  answer  to  Allowable  Limit  Data  Element  Part  5b  must  be 

either  'iil'  (time  unit)  or  '  i  i  i ) '  (time  period);  the  answer 
of  ' i ) '  (number  of  data  entries)  would  not  make  sense. 

An  example  of  this  type  of  allowable  limit  would  be:  "If  two  or  more 
Hazardous  Substance  Incident  Reports  (FT1)  is  entered  for  a  given 
facility  during  the  last  month"  then  the  allowable  limit  has  been  met 
and  a  requirement  should  be  triggered  (where  the  Hazardous  Substance 
Incident  Report  is  a  form  used  for  recording  spills  and  other 
events/accidents  involving  hazardous  substances).  In  this  example. 
Allowable  Limit  Data  Element  Part  2  would  be  'greater  than  1';  the  value 
for  Allowable  Limit  Data  Element  Part  5a  would  be  '30';  and  the  value 
for  Allowable  Limit  Data  Element  Part  5b  would  be  '  i  i ) '  (time  unit)  with 
the  time  unit  specified  as  'days'. 

To  further  clarify  the  difference  between  time  units  and  time  periods 
witn  this  example  we  will  change  this  example  slightly:  If  the 
allowable  limit  had  been  "if  two  or  more  reports  are  entered  during  the 
current  montn",  rather  than  during  the  last  month's  time  (i.e.,  if  the 
time  span  were  to  begin  at  the  beginning  of  the  month  rather  than  30 
days  previous  to  the  entry  of  the  form)  then  Allowable  Limit  Data 
Element  Part  5a  would  have  been  completed  as  ' I '  and  Allowable  Limit 
Data  Element  Part  5b  would  have  been  completed  as  *  i  i  i ) '  (time  period) 
witn  the  time  period  specified  by  a  time  period  spec i f icat ion  identifier 
(Ij24)  tnat  gave  the  beginning  of  the  time  period  as  a  calendar  month. 

1 .  (Allowable  limits  specification)  requirement  application 
identifier  t  105) .  Unique  value  assigned  by  the  program  to 
distinguish  this  set  of  DS17  data. 
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2.  The  form  subpart  identifier  (ID17)  for  which  this  set  of 
DS17  data  constituted  allowable  limits.  This  would  be  left 
blank  if  the  OS  1 7  data  is  for  an  allowable  limit  for  an  entire 
class  of  data,  i.e.,  for  a  form-as-a-whole  type  of  allowable 
limit,  as  defined  in  the  DS10  data  description. 

3.  The  forms  specification  identifier  ( 1016)  for  which  this  set 
of  DS17  data  constitutes  and  allowable  limit  (for 
forms-as-a-whole  allowable  limits). 

4.  OHMIS  service  area  identifier  (ID10)  for  which  this  set  of 
DS17  data  is  specified. 

5 .  Allowable  limit  application  identifier  (ID20)  of  the 
allowable  limit  applicability  values  for  which  this  set  of 
DSl7  data  constitutes  one  set  of  applicable  allowable  limits. 
Would  be  left  blank  if  this  is  the  'default1  allowable  limit. 
If  entered,  the  program  checks  that  this  identifier  is 
consistent  with  the  IDl 7  (or  I D 16 )  and  I  DIO  provided  above. 
Because  there  cannot  be  a  default  set  of  allowable  limits 
(DS17)  data  for  a  forms  subpart/OHMIS  service  area  (or  a 
form- as -a-. .'hole  service  area),  if  there  are  any  allowable 
limits  appl i cab i 1 i ty  factors  and  values  (DS15  and  DS16  data), 
the  DS17  data  entry  program  (Menu  Selection  Sequence  4.1.1) 
will  require  that  there  be  an  ID20  given  for  the  fo*"”. 
subpart/OHMIS  service  area  (or  form-as-a-whole/service  area) 
given  above,  unless  there  is  no  set  of  DS15  data  for  that 
forms  subpart/service  area  or  form-as-a-whole/service  area. 

If  there  is  DSlb  data,  an  allowable  limit  application 
identifier  (1020)  identifying  a  set  of  DSlb  data  corresponding 
to  this  DS15  data  must  be  entered  on  the  DS17  data. 

6.  Date  this  allowable  limits  specified. 

7.  End  date  ( deac t i vat  ion  date)  for  this  al]owable  limit. 

8.  The  O.iiMIS  user  identifier  ( I Dl 3 )  for  the  person  specifying 
this  al  lowab  le  limit. 

9.  The  employee  identifier  (ID4)  for  the  person  promulgating 
tnis  al lowable  1 imit. 

10.  The  OHMIS  user  identifier  ( I Dl 3 )  of  the  person  approving 
deactivation  of  tnis  allowable  limit. 

11.  The  employee  identifier  (ID4)  of  the  above  person. 

12.  Whicn  of  the  forms  units  to  which  this  forms  subpart  (or  forms 
specification)  applies  are  to  be  used  to  define  this  allowable 
limit.  The  answer  may  be  'all'  (it  would  be  'all',  if  there 
was  only  one  forms  unit;  or,  a  subset  of  the  up  to  6  forms 
.nits  for  a  forms  subpart  (up  to  9  forms  units  for  a  forms 
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specification)  specified  in  the  forms  subpart  data  (DS11)  or 
the  forms  specification  data  (DS10).  For  example,  if  the 
forms  unit(s)  for  a  Hazardous  Substance  Incident  Report  (FT1) 
were  an  organizational  unit  and  a  facility,  this  allowable 
limit  may  be  defined  in  terms  of  all  entries  of  this  form  for 
either  a  particular  combination  of  these  two  forms  units  or 
for  only  one  of  these  two  forms  units.  For  example  (using  a 
forms-as-a-whole  allowable  limit  specification)  FT1  may 
provide  data  on  both  the  organ izat ional  unit  and  the  facility 
(and  thus  both  of  these  items  are  forms  units  for  this  type  of 
form),  but  the  allowable  limit  of  "2  or  more  Hazardous 
Substance  Incidents  Reports  in  a  month"  may  apply  only  if  the 
forms  are  submitted  from  the  same  facility  (regardless  of 
the  organizational  unit);  or,  the  allowable  limit  may  specify 
that  the  forms  must  be  submitted  twice  in  a  month  from  the 
same  combination  of  organizational  unit  and  facility  for  the 
allowable  limit  to  be  met.  In  the  first  example,  only  tne 
facility  type  of  forms  unit  is  to  be  used  in  the  evaluation  of 
allowable  limits;  in  the  second  example,  both  of  tne  two  forms 
units  are  to  be  used  in  the  allowable  limits  evaluation. 

13.  Which  of  the  forms  units  are  to  act  as  requirements 
implementation  units  for  any  implementation  of  the  requirement 
(ID6)  identified  below.  The  requirement  implementation 
unit(s)  is  the  person  or  thing  about  which  the  form  is  to  be 
implemented . 

14 .  Narrative  description  of  the  allowable  limit  (supplement  to 
the  requirement  description).  This  describes  the  allowable 
limit  verbally  (as  distinguished  from  the  formatted 
description  of  the  allowable  limit  given  in  the  Allowable 
Limit  Data  Element  Parts).  This  description  is  used  if  a 
manual  check  of  allowable  limits  is  needed  (see  below).  This 
description  also  includes  additional  explanation  of  the 
requirement  triggered  by  this  allowable  limit  (see  requirement 
identifier  (ID6)  below)  beyond  that  given  in  the  requirement 
description  data  (DS1)  that  explains  this  particular 
application  of  the  requirement. 

15.  Answer  to  the  question:  Must  the  determination  of  whether 
there  is  a  match  to  an  allowable  limit  be  made  manually? 
Answer:  Yes/No.  The  0HM1S  DS17  data  is  organized  such  that 
the  OHMIS  program  (using  Function  F3B)  will  be  able  to 
determine  whether  there  is  a  match  to  an  ai lovable  limits 
specification.  However,  to  cover  those  allowable  limits  that 
do  not  fit  the  many  formats  provided  for  specifying  allowable 
limits  given  in  the  OS  1 7  data,  the  user  may  specify  that  the 
evaluation  of  allowable  limits  must  be  done  manually.  If  the 
answer  is  'Yes',  each  time  the  program  determines  that  this 
set  of  1)317  data  is  an  app  1  i cab  1  e  allowable  limit,  the 
program  will  retain  the  allowable  limits  check  request  data 
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(0S18)  generated  during  Function  F3B  so  that  the  user  can  use 
this  data  to  manually  evaluate  the  allowable  limits. 

Allowable  Limits  Data  Elements 

16.  Up  to  12  sets  of  Allowable  Limit  Data  Elements  (i.e.,  the  5 
part  set  of  data  elements  described  above  in  the  introduction 
to  this  description  of  the  DS17  data). 

17.  Allowable  limits  table  identifier  (ID25),  if  any,  for  the 
list  of  allowable  limits  table  data  (DS21)  that  is  to  be  used 
as  allowable  limit  values  (i.e..  Allowable  Limit  Data  Element 
Part  2)  for  this  allowable  limits  specification. 

Requirements  Information 

Id.  Requirement  identifier  (ID6)  for  the  requirement  that  is  to 
be  triggered  (i.e.,  the  requirement  in  which  requirements 
implementation  data  (DS5)  is  to  be  generated)  when  the  values 
entered  on  an  OHMIS  form  match  the  allowable  limits  given  in 
this  set  of  DS17  data. 

19.  The  identifier  for  the  organizational  level  type  (CT5)  at 
which  the  determination  of  whether  the  requirement  applies  is 
to  be  made.  This  can  (and  in  most  cases  will  be)  the 
identifier  for  an  OHMIS  service  area  (ID10),  an  installation 
((Oil),  an  organ izational  unit  (1D12),  a  job  class  (ID7)  or  a 
facility  (IDS)  depending  on  the  purview  of  the  requirement's 
applicability.  The  requirement  description  data  (DS1)  for  the 
above  referenced  requirement  identifier  (ID6)  prescribed  at 
what  type  of  organizational  level  (CT5)  tne  requirement  is 

to  be  applied  (e.g.,  by  service  area,  installation,  etc.); 
this  0S17  data  element  provides  an  actual  value  for  the 
organizational  level  at  which  it  applies.  The  entry  program, 
therefore,  checks  that  the  identifier  value  supplied  here  is 
consistent  with  the  type  of  identifier  for  an  organizational 
level  (CT5)  provided  in  the  DS1  data  for  the  requirement. 

20 .  Description  of  the  conditions  that  triggered  this 
implementation  of  the  requirement.  Used  in  output  such  as 

the  Requirements  Notification  and  Certification  Record  (03)  to 
inform  the  user  of  why  this  requirement  was  implemented.  In 
the  case  of  requirements  triggered  by  allowable  limits,  this 
includes  the  description  of  those  forms  units  and  data  element 
types  the  values  for  which  triggered  the  implementation  of  the 
requirement.  For  example,  if  the  requirement  was  triggered  by 
an  employee  having  a  hearing  test  result  that  exceeded  the 
allowable  limit  above  the  base  line  hearing  test  for  this 
employee,  the  statement  might  read:  "This  requirement  was 
triggered  by  the  entry  of  the  below  referenced  hearing  test 
result  for  the  below  referenced  employee".  This  statement 
would  appear  on  the  03  type  of  output  followed  by  the  values 
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for  the  forms  unit  (in  this  case  an  employee  identifier)  and 
the  data  element  type  (in  this  case  a  hearing  test  result) 
identified  in  this  field  as  narrative  data. 

21.  If  this  is  a  default  allowable  limit  ( i . e - ,  an  allowable  limit 
for  which  there  are  no  allowable  limit  applicability  factors 
(DS15  and  DS16  data))  then  this  field  would  include  a 
statement  to  that  effect. 

22.  Description  of  any  additional  checks  that  the  user  should 
exercise  to  determine  whether  the  requirement  is  applicable 
and  should  be  implemented  beyond  those  specified  in  the 
allowable  limits  data.  This  would  include  restrictions  on  the 
applicability  of  the  requirement  that  cannot  be  specified 
through  allowable  limits  data. 

23.  Description  of  the  Menu  Selection  Sequence,  if  any,  for 
undertaking  the  data  processing  actions  for  the  above 
referenced  additional  checks. 

24.  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier 
( ID14)  for  the  user/position  of  the  person  who  is  to  execute 
this  requirement,  i.e.,  the  primary  person  who  is  to  be 
notified  of  this  requirement.  (See  DS3  data  for  further 
explanation  of  this  field.) 

25.  Same  as  above  for  the  management  person,  if  any,  who  is  to 
be  notified  of  the  requirement  in  order  to  supervise  it's 
execution.  (See  DS3  data  for  further  explanation  of  this 
field. ) 

26.  Same  as  above  for  the  person,  if  any,  who  must  approve  the 
disposition  of  the  requirement.  (See  DS3  data  for  further 
explanation  of  this  field). 
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Allowable  Limits  Check  Request  Data 


This  data  is  used  to  temporarily  store  the  values  needed  for  an 
allowable  limits  evaluation  (Function  F3B)  until  it  can  determine 
whether  there  is  a  match  to  an  applicable  set  of  allowable  limits 
specification  data  (DS17);  at  that  point,  the  DS18  data  is  either  erased 
(if  there  is  no  match)  or  it  is  used  as  a  part  of  the  data  for 
generating  a  set  of  requirements  implementation  data  (DS5)  for  one  of 
the  requirements  that  are  to  be  triggered  by  matching  allowable  limits 
and  tnen  erased. 

The  DS18  data  is  not  entered  by  the  user;  it  is  generated  by  the  program 
as  a  part  of  Function  F3B.  If  the  allowable  limits  evaluation  program 
(part  of  Function  F3B  in  which  data  is  entered  from  completed  OHMIS 
forms)  is  able  to  determine  which  allowable  limits  apply  and  whether  the 
values  entered  from  the  completed  forms  match  the  prescribed  allowable 
limit  values,  then  the  DS18  data  is  erased.  If  the  current  OHMIS  data 
base  does  not  contain  the  information  necessary  to  determine  which 
allowable  limits  specifications  are  applicable  ( i . e . ,  if  it  does  not 
contain  the  values  for  the  allowable  limit  applicability  factors  (0S15 ) ) 
or  if  the  allowable  limit  is  one  that  must  be  evaluated  manually,  the 
Function  F3B  program  retains  the  DS18  data.  The  DSI8  data  is  then  used 
to  notify  the  user  that  an  allowable  limits  check  is  needed,  using  the 
Allowable  Limits  Check  Notice  (09)  and  the  Outstanding  Allowable  Limits 
Checks  Needed  List  (010).  The  DS18  data  is  deleted  at  the  time  that  the 
user  conducts  this  allowable  limits  check  (Function  F3C). 

1.  Allowable  limits  check  request  identifier  ( 1022) .  Unique 
value  assigned  by  the  program  to  distinguish  this  set  of  DS18 
data.  Used  to  execute  the  allowable  limits  check  (Function 
F3C). 

2.  OHMIS  service  area  identifier  (ID10)  for  the  service  area  in 
which  the  completed  form  (DS14)  data  was  generated  for  the 
completed  form  that  triggered  the  allowable  limits  evaluation 
generating  this  set  of  US  18  data. 

3.  D_ate  on  which  this  data  was  generated. 

4.  Completed  forms  idenr  ' >er  U018)  for  the  completed  forms  data 
(DS14)  for  the  form,  ■  >e  entry  of  data  from  which  triggered  the 
allowable  limits  evaluation  that  generated  this  set  of  DS18 
data. 

5.  Completed  forms  ident i r ler  ( 1018^,  if  any,  for  the  last 
completed  form  (t.e.,  US14  data)  of  the  same  form  type  (CT9)  and 
for  the  same  forms  unit(s)  as  the  above  form,  i.e.,  the 
completed  form  that  contains  the  data  obtained  immediately 
before  the  data  on  the  form  referenced  above.  This  form  is 
identified  from  the  current  forms  list  (DL23)  at  the  time  that 
the  above  form  is  entered  (Function  F3B)  and  is  entered  onto 
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both  the  DS14  and  the  DS18  data,  before  the  ID18  on  the  DL23  is 
replaced  by  the  above  "new"  ID18. 

6.  Whether  this  set  of  DS18  data  is  an  allowable  limits  check  for  a 
forms  subpart  (Answer:  '1')  or  for  a  form-as-a-whole  (Answer: 
'2').  As  expl  lined  in  the  allowable  limits  specification  data 
(DS17)  an  answer  of  '2*  means  that  the  allowable  limits  check  is 
to  determine  whether  there  are  any  allowable  limits  on  the  entry 
of  the  entire  class  of  data  covered  by  a  form  of  a  particular 
specif ication  (ID16),  e.g.,  any  allowable  limits  for  the  number 
of  hazardous  substance  spill  reports  entered  for  a  single 
facility,  as  distinguished  from  a  check  for  allowable  limits 
relevant  to  an  individual  data  element  type  entered  for  a 
particular  forms  subpart  on  a  form. 

7.  Forms  specification  identifier  (ID16)  for  the  version  of  the 
form  being  entered,  i.e.,  the  form  version  on  the  set  of  DS14 
data  referenced  by  the  first  ID18  given  above. 

8.  Forms  subpart  identifier  (ID17)  for  the  particular  part  of  the 
form,  if  any,  covered  by  the  allowable  limits  evaluation  in 
which  this  set  of  DS18  data  was  generated.  If  this  is  an 
allowable  limits  evaluation  for  a  form-as-a-whole,  this  data 
element  will  be  left  blank. 

9.  The  data  element  types  (CT4)  and  values  for  the  up  to  6  forms 
units  (up  to  9  for  form-as-a-whole  allowable  limits 
evaluations)  entered  onto  the  form.  This  data  is  obtained  from 
the  DS14  data  corresponding  to  the  first  ID18  above.  The 
completed  forms  data  entry  program  (Function  F3B)  determines 
which  of  the  forms  unit(s)  on  the  form  apply  to  the  forms 
subpart  identifier  (ID17)  for  which  this  allowable  limits 
evaluation  is  being  conducted  (or  applied  to  the 
form-as-a-whole,  if  that  is  the  type  of  allowable  limits 
evaluation  being  conducted)  using  the  forms  specification  data 

( OS 10 )  corresponding  to  the  above  ID16. 

10.  When  of  the  above  forms  units  are  to  be  used  to  evaluate  the 
allowable  limits.  The  answer  given  here  could  be  'all'  or  could 
be  a  series  of  numbers  from  1  to  6  (or  from  1  to  9  for 
forms-as-a-whole)  identifying  the  above  forms  units.  The  data 
comes  from  the  DS17  data  corresponding  to  the  below  referenced 
IDS. 

11 .  The  data  element  types  (CT4)  and  values  for  the  up  to  5 
allowable  limits  applicability  factors  for  each  of  the  up  to  6 
(or  up  to  9)  forms  units  identified  above.  The  Function  F3B 
program  uses  the  allowable  limits  applicability  factors  data 
(DS15)  to  determine  which  data  element  types  are  the  allowable 
limits  applicability  factors  for  this  form  subpart  and  OHMIS 
service  area  or  for  this  form  specification  and  OHMIS  service 
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area.  The  program  then  searches  for  the  values  for  these 
factors  in  the  existing  OHMIS  data  base  and,  if  possible, 
abstracts  them.  If  it  is  not  possible  to  obtain  from  the 
existing  OHMIS  data  base  the  values  for  all  of  the  allowable 
limits  applicability  factors,  an  allowable  limits  check 
(Function  F3C)  request  is  triggered  by  retaining  the  above  ID22 
(allowable  limits  check  request  identifier)  on  the  list  of 
allowable  limits  check  request  identifiers  by  OHMIS  service  area 
(DL17). 

12.  Values  entered  onto  the  above  identified  completed  form,  i.e., 
the  values  from  the  DS14  for  the  first  ID18  given  above  for  the 
up  to  6  data  element  types  that  make  up  the  forms  subpart  data 
for  the  DS11,  identified  by  the  forms  subpart  identifier  (ID17) 
above.  In  other  words,  these  are  the  actual  values  being 
entered  onto  the  OHMIS  data  base  from  this  completed  form  for 
which  an  evaluation  of  allowable  limits  is  being  made.  This 
would  be  left  blank  if  this  is  an  allowable  limits  evaluation 
for  a  form-as-a-whole. 

13.  The  up  to  12  (2  for  the  up  to  6  data  element  types  in  a  form 
subpart)  completed  forms  identifiers  (1018)  for  the  forms 
containing  the  original  baseline  values  and  the  secondary 
baseline  values  used  in  the  allowable  limits  evaluation  covered 
by  this  set  of  DS18  data.  These  fields  are  not  used  for 
forms-as-a-whole  allowable  limits  evaluation.  The  secondary 
baseline  used  in  automatic  allowable  limits  evaluation  that 
takes  place  when  data  from  an  OHMIS  form  is  entered  (i.e., 
Function  F3B)  is  the  1 atest  secondary  baseline  for  the  above 
forms  unit  and  for  the  same  data  element  type  as  that  for  which 
allowable  limits  are  being  evaluated.  (Secondary  baselines  are 
those  values  other  than  the  original  entry  for  the  data  element 
type  and  forms  unit,  i.e.,  other  than  the  original  baseline, 
that  the  user  has  determined  should  be  used  as  a  baseline 
value.)  If  there  is  no  secondary  baseline,  the  secondary 
baseline  is  left  blank.  For  allowable  limits  checks  (Function 
F3C)  that  are  done  by  the  user  (rather  than  automatically),  the 
user  can  specify  which  secondary  baseline  is  to  be  used. 

There  can  be  up  to  6  1018s  for  original  baseline  entries  and  6 
I D 1 8s  for  secondary  baseline  entries  (for  a  total  of  12),  if  the 
baseline  values  that  are  automatically  used  or  are  chosen  have 
been  entered  on  different  forms  for  each  of  the  up  to  6  data 
element  types  in  a  forms  subpart. 

14.  The  values  for  the  above  12  baseline  entries.  Can  be  up  to  12 
values,  2  for  each  of  the  data  element  types  in  the  forms 
subpart  (1017)  being  covered  by  this  allowable  limits 
evaluation. 
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15.  The  forms  containing  the  baseline  entries  and  the  values  for  the 
baseline  entries  are  entered  on  the  DS18  data  in  order  to 
facilitate  the  manipulation  of  data  needed  to  evaluate  an 
allowable  limit.  These  are  also  used  in  the  outputs  to  tell  the 
user  of  the  circumstances  under  which  an  allowable  limit  was  met 
for  those  outputs  that  cover  requirements  generated  by  allowable 
limits.  However,  many  of  the  allowable  limits  will  not  use 
baseline  entries  to  define  the  allowable  limits.  In  these 
cases,  there  will  be  no  need  to  identify  the  baseline  entry 
values  to  conduct  the  allowable  limits  evaluation  and, 
therefore,  the  fields  covering  baseline  entries  on  the  DS18  data 
will  be  left  blank . 

16.  The  allowable  limits  application  identifier  (ID20)  for  the  set 
of  allowable  limits  applicability  values  (DS16)  which  was  found 
to  match  the  values  entered  above  for  forms  units  and 
applicability  factors.  Th  ;  ID20  indicates  which  set  or  series 
of  sets  of  allowable  limits  specification  data  (DS17)  are  to  be 
used  to  determine  whether  the  values  entered  on  the  form  match 
an  allowable  limit.  This  identifier  would  be  left  blank  if  the 
OHMIS  program  was  not  able  to  abstract  the  values  for  all  of  the 
allowable  limit  applicability  factors  (as  identified  in  DS15 
data)  for  the  particular  set  of  forms  units  entered  on  this 
completed  form  and  thus  was  unable  to  determine  whether  a  set  of 
allowable  limits  applicability  values  (DS16)  matched  the 
corresponding  values  for  these  forms  units.  This  1020  field  is 
left  blank  if  this  set  of  DS18  data  is  for  an  allowable  limit 
specification. 

17.  (Allowable  limits  specification)  requirement  application 
identifier  (ID5)  for  the  set  of  allowable  limits  specification 
data  (DS17)  found  to  be  applicable.  This  would  be  left  blank 
during  the  Function  F3B  if  the  program  is  not  able  to  identify 
the  applicable  allowable  limits.  The  Function  F3B  program 
identifies  the  applicable  allowable  limit  (ID5)  and  enters  it  on 
the  DS18  data.  The  program  then  determines  whether  it  is  the 
type  of  allowable  limit  for  which  the  program  can  determine  if 
there  is  a  match  to  the  data  entry  on  the  form  being  entered, 
i.e.,  whether  it  has  been  possible  to  enter  the  entire  allowable 
limits  specification  in  the  Allowable  Limit  Data  Element  Parts 
format  provided  or  whether  a  manual  check  for  allowable  limits 
is  needed.  If  the  answer  is  ’Yes'  (no  manual  check  needed),  the 
program  proceeds  with  determining  whether  there  is  a  match  to 
the  allowable  limit  and  then  erases  the  DS18  data.  If  the 
answer  is  *  No '  (i.e.,  a  manual  check  is  needed  to  determine  if 
there  is  a  match  with  this  allowable  limit  specification),  the 
identifier  (ID5)  for  the  allowable  limits  specification  is 
retained  on  the  DSI8  data  (i.e.,  the  DS18  data  is  not  erased)  in 
order  to  enable  the  DS18  data  to  be  used  to  inform  the  user  on 
the  Allowable  Limits  Check  Notice  (09)  of  which  allowable  limits 
specification  is  to  be  checked.  In  other  words,  the  DS18  data 
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that  has  an  ID5  on  it  will  only  be  kept  (not  erased)  if  it  is 
the  type  of  allowable  limits  specification  that  requires  a 
manual  check.  The  only  other  reason  for  retaining  the  DS18  data 
would  be  that  it  was  not  possible  to  automatically  determine 
from  the  current  OHMIS  data  base  which  of  the  allowable  limits 
specifications  were  applicable;  in  this  case,  the  ID5  would  not 
be  completed. 


DATA  SET  19 


Missing  Data  Element  Information 


This  data  describes  one  piece  of  information  that  is  currently  missing 
from  the  OHMIS  data  base.  Missing  information  is  defined  as  information 
for  which  a  value  could  not  be  entered  (i.e.,  the  data  element  type  was 
on  a  forms  specification  or  was  normally  part  of  the  data  supplied  at 
the  time  by  a  given  External  Data  Source  (EDS)  such  as  SIDPERS)  but  was 
not  entered. 

DS19  data  is  generated  by  the  program  at  the  time  that  the  data  is 
supposed  to  have  been  entered  from  an  OHMIS  form  (Menu  Selection 
Sequence  3.1;  Function  F3B  for  adding  completed  forms  data  (DS14)  and 
Menu  Selection  Sequence  3.3  for  changing  completed  forms  data)  or  when 
data  is  extracted  from  an  External  Data  Source  and  found  to  be  missing. 
The  missing  data  element  list  (DL25)  provides  an  index  to  the  DS19  data 
by  identifier.  This  list  is  used  to  identify  all  missing  data  elements 
for  a  given  forms  unit  identifier  (e.g.,  an  employee)  at  the  time  that 
an  OHMIS  blank  form  is  generated  for  that  identifier  (Menu  Selection 
Sequence  2.1.5;  Function  F3A)  so  that  a  special  'Missing  Data  Element 
Type  Form'  can  be  generated  to  obtain  all  missing  data  elements  for  that 
identifier  (e.g.,  for  the  employee  for  which  a  blank  OHMIS  form  is  being 
generated).  Thus,  the  OHMIS  program  provides  for  routinely  obtaining 
missing  information  (using  a  missing  data  element  type  form)  whenever  a 
form  is  generated  for  a  identifier  that  is  shown  on  the  DL25  list  to 
have  values  for  data  elements  missing.  For  example,  whenever  an 
employee  is  about  to  come  to  the  OHMIS  for  a  medical  exam,  the  process 
of  generating  a  blank  form  on  which  to  conduct  that  medical  exam  ( i . e . , 
Function  F3A)  will  automatically  result  in  a  search  to  determine  if 
there  are  any  missing  data  elements  for  that  employee  in  the  OHMIS  data 
base  and,  if  so,  the  generation  of  a  Missing  Data  element  Type  Form  to 
obtain  those  missing  data  element  types. 

Only  current  DS19  data  is  maintained.  The  data  is  deleted  and  removed 
from  the  DL25  list,  at  the  time  that  the  user  suppl ies  the  missing 
information.  This  can  be  done  during  Menu  Selection  Sequence  3.5  or  by 
entering  the  data  from  a  Missing  Data  Element  Type  Form.  Information  is 
considered  missing  as  long  is  there  is  no  answer  provided,  i.e.,  the 
field  is  left  blank.  A  value  of  'unknown'  or  'not  applicable'  is 
considered  to  be  an  answer  and  would  not  therefore  be  a  missing  data 
element. 

1.  Missing  data  element  information  identifier  (ID21).  Unique 
value  assigned  by  the  program  to  distinguish  this  set  of  DS19 
data. 

2.  Data  element  type  code  (CT4)  for  the  data  element  type  that 
has  a  missing  value. 

Up  to  six  forms  unit  identifiers  for  the  identifier  or  set 
of  identifiers  about  which  the  data  element  type  is  missing. 


3. 
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For  example,  if  an  employee's  date  of  birth  is  the  missing 
data  element  type,  it  is  that  employee's  identifier  ( 1 04 J  that 
would  be  placed  in  this  field.  If  the  information  was 
identified  as  missing  during  the  entry  of  completed  forms  data 
(DS14)  for  an  OHMIS  form,  this  identifier  would  be  the  forms 
unit  identifier(s)  for  the  missing  data  element  type  (as 
defined  in  the  forms  specification  data  (DS10))  for  that  form 
and  for  the  forms  subpart  from  which  the  data  element  type  was 
missing.  The  will  normally  be  only  1  identifier,  but  some 
data  element  types  describe  a  relationship  between  more  than 
one  identifier  and  therefore  multiple  identifiers  may  be  used 
to  a  maximum  of  the  6  forms  unit  identifiers  allowed  for  a 
single  forms  subpart  on  the  DS10  data.  The  DL25  provides  a 
index  to  the  missing  data  element  types  by  this  identifier  or 
set  of  identifiers.  This  is  done  in  order  that  all  missing 
data  element  types  for  a  given  identifier  (e.g.,  for  a  given 
employee)  can  readily  be  identified. 

4.  Date  that  the  above  data  element  type  was  found  to  be 
missing. 

5.  Completed  form  identifier  (ID18)  of  the  completed  form 
(DS14),  if  any,  for  which  this  data  element  type  is  currently 
missing.  This  field  would  be  left  blank  if  the  data  is  not 
missing  from  an  OHMIS  form,  e.g.,  if  it  is  obtained  from  an 
External  Data  Source. 

6.  The  forms  subpart  identifier  ( I Dl 7 )  for  the  forms  subpart  on 
the  completed  forms  data  ( DS 14 )  identified  by  the  above  ID18 
from  which  this  data  element  type  is  currently  missing. 

7.  The  location  in  which  the  value  for  the  missing  data  element 
type  is  to  be  stored  once  it  is  obtained.  This  information  is 
transparent  to  the  user  and  will  depend  on  the  files  of 
storage  configuration  selected  for  OHMIS.  However,  it  is 
anticipated  that  the  location  will  be  defined  in  terms  of  the 
completed  forms  identifier  ( I  Dl 8 )  for  the  form  from  which  the 
missing  data  element  type  is  missing,  for  data  element  types 
missing  from  OHMIS  forms  and/or  in  terms  of  the  unit  described 
by  the  data  element.  The  storage  information  is  on  the  DS7 
data  for  the  data  element. 

8.  The  completed  form  identifier  (ID18)  for  the  current 
outstanding  (uncompleted)  Missing  Data  Element  Type  Form 
containing  a  request  for  this  missing  data  element,  if  any. 
When  a  Missing  Data  Element  Type  Form  is  generated  in  Function 
F3A,  this  field  is  completed,  otherwise  it  is  left  blank. 

When  the  values  for  the  completed  Missing  Data  Element  Type 
Form  are  entered  (Function  F3B),  either  the  entire  DS19  data 
is  deleted  (because  the  value  for  the  date  element  type  is  no 
longer  missing)  or,  if  the  value  for  this  data  element  type  is 
not  entered  at  that  time  (i.e.,  it  is  still  missing)  the  I Dl 8 
for  the  Missing  Data  Element  Type  Form  is  removed  from  this 

DS 1 9  data  set. 
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Time  Period  Specification  Data 


This  data  is  used  to  define  a  particular  time  period.  This  definition 
is  used  in  several  ways  in  the  OhMIS  data  base.  For  example,  it  is  used 
when  specifying  the  time  span  information  part  of  the  Allowable  Limits 
Data  Elements  (see  allowable  limits  specif ication  data  ( DS1 7 ) ) .  The 
same  set  of  DS20  data  is  used  for  all  OHMIs  service  areas.  DS20  data  is 
entered  by  the  user  using  Menu  Selection  Sequence  6.1.  DS20  data  cannot 
be  changed  or  deleted. 

A  series  of  sets  of  DS20  data  defining  the  most  common  (calendar)  time 
periods  will  be  input  at  the  beginning  of  the  OHMIS  program  and  it  is 
expected  that  there  will  not  be  many  additional  time  periods  added. 
However,  for  some  types  of  time  periods  the  'begin  time'  for  the  time 
period  may  need  to  be  varied.  For  example,  although  all  radiation 
exposure  measurements  may  be  on  the  same  time  period  unit  (quarters), 
different  installations  may  have  different  begin  dates  for  the  quarter, 

i.e.,  the  quarter  does  not  necessarily  always  begin  on  the  first  day  of 
each  first,  forth,  seventh  and  tenth  calendar  months  in  a  year.  AS 
described  in  the  OS  1 7  data,  time  periods  are  distinguished  from  time 
units  in  that  they  have  a  specified  begin  date. 

1.  Tune  period  specification  identifier  (ID24).  Unique  value 
assigned  by  the  program  to  distinguish  this  set  of  DS20  data. 

2.  T ime  period  unit.  Answers  include:  Minutes,  hours,  days, 
weeks,  months,  quarters,  semesters,  years,  etc.  If  this  is  a 
time  period  data  set  defining  a  time  period  from  a  given  date 
to  the  present,  then  there  would  be  a  code  in  this  field 
indicating  this,  e.g.,  code  'NS'  for  Nonstandard  time  period. 

3.  Begin  time.  This  is  specified  using  one  of  several 
different  formats  depending  on  the  time  unit.  Examples  are: 

o  Minutes:  Value  from  1  to  60  (indicating  the 
starting  second). 

o  Hours:  Value  from  1  to  60  (indicating  the  starting 
minute) . 


o  Days:  Values  from  1  to 
hour)  and  values  from  1 
starting  minute  for  the 

o  Weeks:  Value  from  1  to 

of  the  week)  and  values 
and  1  to  60  < starting  m 

o  E  tc . 


24  (indicating  the  starting 
to  60  (  indicating  the 
hour). 

7  (indicating  the  start  day 
from  1  to  24  (starting  hour) 
nute  of  the  hour). 
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If  this  is  a  Nonstandard  type  of  time  period,  the  begin  date 
would  be  and  hour,  day,  month,  and  year. 

The  format  for  entering  the  begin  time  information  is  to 
provide  the  begin  time  for  each  of  the  time  units  there  are 
smaller  than  the  time  units  specified  above.  Thus,  if  the 
time  unit  specified  above  was  'quarter'  the  user  must  indicate 
begin  time  (1  through  12)  and  day  of  the  month  (1  through  31); 
the  user  would  probably  set  the  hour  of  the  day,  the  minutes 
of  the  hour  and  the  seconds  of  the  minutes  at  ‘O' . 
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Allowable  Limits  Table  Data 


This  data  is  used  to  specify  the  values  for  a  table  that  should  be  used 
when  evaluating  allowable  limits.  The  allowable  limits  specification 
data  (DS17)  specifies  which  table  (i.e.,  which  series  of  DS21  data 
sets),  if  any,  is  to  be  used  as  the  prescribed  allowable  limits  values, 
by  providing  an  allowable  limits  table  identifier  (ID25). 

Allowable  limits  tables  are  used  for  specifying  allowable  limits  when 
there  is  a  large  series  of  combinations  of  allowable  limits  (each 
combination  bearing  the  same  relationship  to  each  other)  that  apply. 

For  example,  if  the  allowable  limit  for  air  flow  on  a  fume  hood  depends 
on  the  amount  of  the  substance  used  in  the  fume  hood,  then  this 
information  (i.e.,  this  relationship)  could  be  portrayed  as  a  table 
showing  combinations  of  air  flow  values  and  amounts  of  hazardous 
substance  values.  The  relationship  between  these  combinations  of  data 
element  types  is  prescribed  in  the  allowable  limits  specification  data 
(DS17)  which  specifies  this  table  as  the  allowable  limits  table  to  be 
used  for  evaluating  allowable  limits. 

All  of  the  data  element  types  in  an  allowable  limits  table  must  belong 
to  the  same  forms  subpart  (DS11).  Therefore,  the  allowable  limits  table 
can  consist  of  combinations  of  up  to  6  data  element  types  (the  maximum 
in  a  forms  si'bpart).  One  set  of  allowable  limits  data  (DS21) 
constitutes  a  single  combination  of  allowable  limits  values  for  these 
data  element  types.  All  combinations  of  allowable  limits  for  a  given 
allowable  limit  table  identifier  (W25),  e.g.,  all  sets  of  amounts  of 
air  flow  and  amounts  of  hazardous  substance,  are  listed  on  an  allowable 
limits  table  list  ( D L 1 9 ) .  The  0119  lists  all  active  DS21  data  for  a 
given  1025. 

0S21  data  is  entered  by  the  user  using  Menu  Selection  Sequence  4.5.1 
(for  adding  0S21  data  to  an  existing  allowable  limits  table  ( DL19 ) )  or 
Menu  Selection  Sequence  4.5.2  for  starting  a  new  allowable  limits  table. 
Historical  0S21  d_ta  is  kept.  DS 21  data  cannot  be  changed  or  deleted. 

If  a  set  of  DS21  uata  is  no  longer  valid,  it  is  deactivated  using  Menu 
Selection  Sequence  4.5.3.  If  al 1  DS21  data  for  a  given  ID25  are 
deactivated,  then  the  program  will  require  that  all  of  the  DS17  data 
containing  that  ID25  also  be  deactivated.  The  source  information  for 
and  identity  of  the  person  promulgating  the  allowable  limits  table  is 
given  in  the  requirements  description  data  (DS1)  referred  to  by  tti^ 
requirement  ident i f ier ( s)  ( 1  Do )  in  the  JS17  data  using  the  ID25  for  this 
set  of  DS21  data. 

Because  the  DS 1 7  data  referring  to  the  0S21  data  also  specifies  the 
requirement  identifier  (ID6)  for  the  requirement  that  is  to  be  triggered 
;f  there  is  a  match  to  the  allowable  limits,  different  series  of  DS 21 
data  (i.e.,  different  tables  of  allowable  limits)  must  be  generated  e.k.n 
time  there  is  a  different  requirement  that  is  to  be  triggered,  for 
example,  if  a  different  requirement  is  to  be  triggered  't  the  an-  ♦’  * 
is  less  than  twice  the  allowaole  limit  than  it  is  it  i:  1  ■  •  •  • 
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twice  the  allowable  limit,  then  two  sets  of  tables  and  two  sets  of  DS17 
data  (each  referring  to  different  requirements)  would  need  to  be 
generated. 

The  DS21  data  entry  program  (Menu  Selection  Sequence  5.4.1)  checks  that 
for  the  same  ID25  there  are  no  overlapping  or  inconsistent  allowable 
limits  in  the  same  allowable  limits  table. 

1.  Allowable  limits  table  identifier  (ID25).  If  the  user  is 
starting  a  new  table  (Menu  Selection  Sequence  4.5.2),  this  is 
a  unique  value  assigned  by  the  program  to  distinguish  this 
series  of  sets  of  DS21  data.  If  the  user  is  adding  to  an 
existing  table  (Menu  Selection  Sequence  4.5.1),  the  user 
specifies  the  ID25  and  the  program  locates  the  corresponding 
DL19  with  that  ID25  and  adds  the  new  DS21  data  to  that  list. 

2.  One  combination  of  allowable  limits  values,  i.e.,  I.E., 
Allowable  Limits  Data  Element  Part  2  given  in  a  set  of  DS17 
data,  for  the  up  to  6  data  element  types  that  make  up  the 
forms  subpart  data  (DSll)  for  which  the  allowable  limits 
specification  data  (DS17)  referring  to  this  allowable  limits 
table  is  specifying  allowable  limits.  In  the  above  example, 
this  would  be  the  value  of  the  air  flow  and  the  value  of  the 
amount  of  the  hazardous  substance  that  constitutes  an 
allowable  (or  unallowable)  limit. 

3.  Date  this  DS21  data  was  generated. 

4.  Date  this  DS21  data  was  deactivated  (may  be  blank). 
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Outstanding  (Uncompleted)  Forms  Monitoring  Data 


This  data  describes  the  characteristics  of  each  outstanding  OHMIS  form, 
i.e.,  each  form  for  which  a  'blank'  form  (output  012)  has  been  generated 
(i.e.,  in  Function  F3A)  but  for  which  the  data  has  not  yet  been  entered 
onto  the  OHMIS  data  base.  The  primary  purpose  of  this  data  is  to 
monitor  for  forms  that  are  overdue  and  thereby  facilitate  the  flow  of 
data  in  OHMIS.  This  data  set  also  keeps  track  of  the  data  element  types 
on  Missing  Data  Element  Type  Forms,  i.e.,  forms  generated  by  the  OHMIS 
program  to  capture  data  elements  that  are  missing  from  the  OHMIS  data 
base.  The  DS22  data  can  thus  also  be  used  to  reproduce  a  copy  of  a 
partially  blank  form  that  has  already  been  previously  generated,  i.e.,  a 
blank  form  that  has  the  forms  units  and  other  identification  on  it.  The 
0S22  data  is  also  used  when  entering  data  from  an  OHMIS  form  (Function 
F3B)  to  provide  the  identification  information  on  the  form  so  that  the 
user  does  not  have  to  re-enter  it.  This  identification  information  was 
entered  on  the  DS14  data  corresponding  to  the  form  at  the  time  the  form 
was  generated. 

The  DS22  data  is  used  to  generate  the  Outstanding  Data  Request  Lists 
(013).  This  output  is  generated  daily  by  the  OHMIS  program  (Function 
F1A)  to  tell  the  user  of  the  forms  that  are  still  uncompleted.  Because 
so  much  of  the  management  of  the  OHMIS  program  involves  the  task  of 
generating  and  completing  OHMIS  forms,  the  Outstanding  Data  Request  List 
(013)  generated  from  the  DS22  data  is  expected  to  be  a  useful  auditing 
tool  for  assessing  the  overall  status  of  the  OHMIS  program  in  any  OHMIS 
service  area.  It  will  also  be  useful  to  the  OHMIS  Data  Processing  Staff 
in  each  OHMIS  service  area  as  a  data  management  tool. 

DS22  data  is  generated  by  the  program  whenever  the  user  requests  that  a 
'blank*  form  be  generated  for  use  in  data  entry  (as  distinguished  from 
generating  a  blank  form  for  examination  only),  i.e.,  during  Function  F3A 
(Menu  Selection  Sequence  2.1.5).  Only  current  DS22  data  is  maintained. 
The  DS22  data  is  deleted  when  the  data  from  the  completed  form  is 
entered  or  when  the  user  indicates  that  the  form  is  not  going  to  be 
completed  (Menu  Selection  Sequence  3.1;  Function  F3B). 

1.  Completed  form  identifier  (1018).  This  is  the  identifier 

assigned  by  the  program  to  the  OHMIS  form  for  which  this  DS22 
data  is  monitoring  completion. 

2  Date  this  DS22  data  was  generated. 

3.  Is  this  form  a  Missing  Data  Element  Types  Form?  Answers: 
Yes/ho.  (See  the  missing  data  element  information  data  set 
(DS19)  for  the  meaning  of  a  Missing  Data  Element  Type  Form.) 

If  the  answer  is  'Yes’,  the  forms  type  code  (CT9)  given  below 
is  a  fixed  code  (always  the  same)  and  there  is  no  forms 
specification  identifier  (ID16). 
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4.  Forms  type  code  (CT9)  for  the  form  being  monitored,  i.e., 
the  form  with  the  ID18  given  above. 

5.  Forms  specification  identifier  ( 1016)  for  the  form 
identified  above. 

6.  OHMIS  service  area  identifier  ( 1010)  for  the  service  area 
generating  this  form. 

7.  OHMIS  user  identifier  (ID13)  or  position  identifier  (ID14) 
for  the  person  to  whom  this  form  is  to  be  sent,  i.e.,  the 
person  who  is  supposed  to  complete  this  form.  This  could  be 
an  employee  identifier  < ID4)  if  the  person  is  not  an  OHMIS 
user  or  does  not  fill  an  OHMIS  position.  This  identifier  is 
obtained  from  the  forms  specification  data  (DS10)  if  the 
user/position  who  is  supposed  to  complete  the  form  has  been 
specified;  otherwise,  it  is  obtained  from  the  user  when 
generating  the  form. 

8.  Employee  identifier  (ID4)  for  the  above  person.  Obtained 
from  the  user/position  identity  and  address  data  (DS9)  for  the 
above  ID13  or  1014. 

9.  OHMIS  user  identifier  (ID13)  of  the  user  who  requested  this 
data.  For  example,  if  the  form  was  one  that  was  filled  out  by 
a  supervisor  (the  above  identifier),  this  identifier  would 
indicate  who  generated  the  request  for  the  data  on  this  form 
from  the  supervisor.  This  might  be  the  Industrial  Hygienist 
for  the  OHMIS  service  area  or  the  Occupational  Health  Nurse  or 
an  equivalent  user. 

10.  Employee  identifier  (ID4)  for  the  above  person. 

11 .  The  OHMIS  user  identifier  (ID13)  or  position  identifier 

( 1014)  for  the  person  who  is  supposed  to  review  (sign  off 
on)  this  form,  if  any.  This  could  be  an  employee  identifier 
(104)  if  the  person  is  not  an  OHMIS  user  or  does  not  fill  and 
OHMIS  position.  This  identifier  is  obtained  from  the  forms 
specification  data  (DS10),  if  the  user/position  who  is 
supposed  to  sign  off  on  this  form  has  been  specified; 
otherwise,  it  is  obtained  from  the  user  when  generating  the 
form. 

12.  Employee  identifier  (ID4)  for  the  above  person.  Obtained 
from  the  user/position  identity  and  address  data  (DS9)  for  the 
above  1013  or  1014. 

13.  Amount  of  time  from  the  date  that  this  set  of  DS22  data  was 
generated  at  which  this  form  will  be  considered  to  be  overdue. 
May  be  from  the  0S10  data  or  may  be  specified  by  the  user. 
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Must  be  later  than  the  date  given  above  for  the  date  that  this 
set  of  DS22  data  was  generated. 

14.  Values  (identifiers)  for  the  up  to  9  forms  units  on  this 
form.  For  example,  if  this  is  a  preemployment  physical  for  an 

employee,  the  forms  unit  would  be  an  employee  identifier 
(ID4).  The  forms  specification  data  (DS10)  specifies  the 
number  and  type  of  forms  units  for  each  forms  specification. 

If  this  is  a  Missing  Data  Element  Type  Form,  there  would  be  a 
value  for  only  one  forms  unit,  that  for  which  the  missing  data 
is  missing. 

15.  If  this  DS22  data  is  for  a  Missing  Data  Element  Type  Form,  up 
to  20  Missing  Data  Element  Type  Information  Identifiers  (ID21) 
for  the  data  on  the  missing  data  element  types. 

16.  The  completed  form  identifier! s)  (ID18)  for  the  other  form 
generated  at  the  same  time  that  this  form  was  generated,  if 
any.  If  this  is  DS22  data  for  a  Missing  Data  Element  Type 
Form,  then  the  other  form  would  be  the  form  that  was  being 
generated  at  the  time  that  this  Missing  Data  Element  Type  Form 
was  triggered  (i.e.,  the  form  containing  the  forms  units  for 
which  this  Missing  Data  Element  Type  Form  contains  the 
currently  missing  data  element  types).  If  this  is  not  a 
Missing  Data  Element  Type  Form,  then  this  completed  form 
identifier  would  be  the  identifier  for  the  Missing  Data 
Element  Type  Form  or  Forms  (up  to  9,  one  for  each  forms  unit 
on  the  form  begin  generated),  if  any,  generated  at  the  same 
time  that  this  form  was  generated. 
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Task  Type  Description  Data 


This  data  describes  a  particular  type  of  task.  A  task  type  is  a  type  of 
action  that  the  OHMIS  user  has  identified  and  described  in  order  that 
the  OHMIS  program  be  able  to  use  this  information  to  automatically 
schedule  action  (Function  F4)  as  these  actions  are  triggered  by 
requirements.  Specifically,  the  OHMIS  scheduling  program  (F4)  uses 
information  about  tasks  to  schedule  the  action  specified  in  the  OHMIS 
requirements  description  data  (DS1)  when  these  requirements  have  been 
triggered  as  indicated  by  the  generation  of  requirements  implementation 
data  (DS5).  Whenever  DS5  data  is  generated,  the  OHMIS  program  examines 
the  DS1  data  to  determine  if  there  is  a  task  type  code  given  (CT8) 
given,  i.e.,  if  the  requirement  is  for  an  action  that  needs  to  be 
scheduled.  If  it  is,  the  program  uses  the  DS23  data  to  generate  a  set 
of  specific  tasks  scheduling  data  (DS24)  thereby  scheduling  the 
execution  of  the  task  associated  with  the  triggered  requirement. 

A  task  type  (CT8)  which  is  described  in  the  DS23  data  is  distinguished 
from  a  task  identifier  (ID23)  which  is  described  in  the  specific  task 
scheduling  data  (DS24).  An  example  of  a  task  type  is  "conduct  a 
Industrial  Hygiene  survey  of  a  facility",  while  the  comparable  example 
of  a  task  identifier  would  be  "conduct  an  Industrial  Hygiene  survey  in 
facility  X  on  date  Y".  Thus  the  DS23  data  provides  the  generic 
information  about  a  task  that  is  true  for  all  executions  of  tasks  of 
that  type,  while  the  DS24  data  describes  the  specific  characteristics  of 
a  particular  execution  of  a  task. 

The  DS23  data  is  entered  by  the  user  using  Menu  Selection  Sequence  7.1. 
The  DS23  data  can  be  thought  of  as  a  thesaurus  on  task  types  (CT8), 
i.e.,  a  fixed  set  of  definitions  about  a  task;  like  any  definition  this 
data  must  remain  unchanged  and  apply  universally  in  order  to  maintain 
the  integrity  of  other  parts  of  the  OHMIS  data  base  in  which  it  is  used. 

This  data  is  not  dated  (does  not  have  start  or  closing  dates).  The 

DS23  data  cannot  be  deleted  or  changed.  The  same  task  type  codes  (CT8) 
apply  throughout  the  OHMIS  system,  i.e.,  in  all  OHMIS  service  areas. 
However,  there  may  be  more  than  one  DS23  data  set  for  the  same  general 
type  of  task,  if  it  is  necessary  to  have  the  same  tasks  shown  with 
different  hours  required  for  completing  the  task.  For  example,  if  one 
OHMIS  service  are  finds  that  because  of  travel  time  or  other  reasons  it 

takes  6  hours  to  conduct  an  average  Industrial  Hygiene  survey,  while  in 

other  areas  it  takes  4,  the  service  area  may  generate  a  new  set  of  DS23 
data  for  the  same  task  showing  the  greater  number  of  hours  for  the  task. 
This  new  DS23  data  would  have  a  new  task  type  code  (CT8). 

1.  Task  type  code  (CT8).  Unique  value  assigned  by  the  program 
to  distinguish  this  set  of  DS23  data. 

2.  Brief  description  of  this  type  of  task.  This  is  the 
description  used  on  summary  outputs,  such  as  the  Daily 
Schedule  (014)  to  briefly  describe  the  task.  This  may  be  the 


.  Ao  '• 


DATA  SET  23 


same  as  the  OHMIS  vocabulary  word/phrase  that  describes  this 
task  type  code  (CT8). 

3.  Detailed  description  of  this  type  of  task.  Used  to  clarify 

to  the  user  the  exact  nature  of  the  task  on  nonsummary  outputs 
such  as  the  Scheduled  Task  Description  (016).  May  include 
references  to  document  identifiers  (ID3)  that  give  further 
explanations  of  this  task. 

4.  Description  of  task  to  be  used  on  the  Scheduling  Notice 
(015) ,  i.e.,  to  tell  a  participant  in  the  task  (not  the 
person  conducting  the  task)  about  the  event  (e.g.,  a  medical 
exam  for  which  he/she  has  been  scheduled. 

5.  Description  of  preparation  for  this  type  of  task.  This  is  a 
narrative  description  of  what  is  required  to  prepare  to 
conduct  the  task.  Would  include  reference  to  document 
identifiers  (ID3)  for  further  information,  such  as  that 
contained  in  manuals,  on  how  to  prepare  for  the  task. 

Includes  the  form  type  code  of  the  forms  that  must  be 
generated  in  order  to  complete  the  task  (e.g.,  a  facility 
survey  form  would  be  needed  for  the  task  of  conducting  an 
Industrial  Hygiene  survey). 

6.  Special  instructions  to  a  participant  in  the  task  (e.g.,  the 
employee  being  scheduled  for  a  medical  exam),  if  any,  on  how 
to  prepare  for  the  event  covered  by  the  task.  An  example 
would  be  an  instruction  not  to  eat  breakfast  on  the  day  of  the 
test. 

7  Standard  Number  of  time  slots  needed  to  conduct  this  type  of 
test.  A  time  slot  is  a  quarter  of  an  hour  period.  This 
information  is  used  to  schedule  tasks  of  this  type. 

8.  Calendar  time  allowed  to  complete  this  task.  This  is  used 
to  generate  a  due  date  for  the  task  (unless  the  task  already 
has  a  due  date  because  it  is  for  a  requirement  that  was 
triggered  by  a  suspense  date,  i.e.,  triggered  by  DS4  data). 

May  be  left  blank  if  no  length  of  time  allowed  to  complete  the 
task  is  to  be  specified. 

9.  Time  use  code  (CT11)  for  the  type  of  time  use  involved  in 
completing  a  task  of  this  type.  In  order  to  insure  that  tasks 
which  are  similar  to  each  other  are  scheduled  next  to  each 
other  where  possible,  each  type  of  task  is  classified 
according  to  the  type  of  time  use  involved.  In  general  these 
time  uses  will  be  based  on  the  type  of  location  in  which  the 
user  must  perform  the  task  but  other  criteria  can  be  used  for 
classifying  the  tasks.  Examples  of  such  classifications  would 
be  "in  the  field",  "in  the  OHMIS  clinic",  etc.  The 
classification  of  tasks  in  this  way  reduces  the  number  of 
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instances  in  which  the  user  is  scheduled  to  perform  a  task  in 
the  field  (e.g.,  an  Industrial  Hygiene  survey)  followed  by  a 
task  in  the  Industrial  Hygiene  office  and  then  followed  by  a 
third  task  back  out  in  the  field.  When  the  user  provides 
schedule  availability  data  (DS26  and  DS27),  he/she  indicates 
his/her  "preferred  time  use”  by  placing  a  time  use  code  (CT11) 
next  to  each  time  slot  available  for  scheduling.  This  enables 
the  user  to  ensure  that  the  OHMIS  program  will  schedule  blocks 
of  time  according  to  his/her  preferences,  where  possible, 
e.g.,  Monday/Wednesday/Friday  in  the  field,  Tuesday/Thursday 
in  the  office.  The  OHMIS  program  (Function  F4)  matches  task 
types  with  a  given  time  use  code  to  the  time  slots  that  have 
been  designated  by  the  user  with  the  same  time  use  code. 

10.  Whether  this  type  of  task  has  any  qualifications  needed  to 
perform  it~!  Answers  of  'No'  would  mean  that  all  OHMIS 
users/positions  in  an  OHMIS  service  area  for  which  there  is 
regular  weekly  schedule  availability  data  (DS26)  would  go  on 
the  list  of  qualified  employee  identifiers  (ID4)  by  task  type 
(CT8)  by  OHMIS  service  area  (DL34).  If  the  answer  is  'Yes', 
it  means  that  the  employee  identifier  of  an  OHMIS  user  or  a 
person  filling  an  OHMIS  position  must  be  on  the  DL34  list  for 
this  task  type  (CT8)  for  tasks  of  this  type  to  be  scheduled 
for  performance  by  that  employee.  Note:  The  specifications 
for  the  type  of  OHMIS  user/position  (given  below)  allowed  to 
conduct  this  type  of  task  need  not  be  filled,  even  if  the 
answer  to  this  field  is  'Yes'.  That  is,  it  is  possible  to 
indicate  that  the  users/positions  performing  this  task  must  be 
qualified  (i.e.,  must  be  on  the  DL34  list)  without  specifying 
what  type  of  user/position  are  to  be  allowed  to  perform  this 
type  of  task. 

11.  OHMIS  user  type  code(s)  (CT1)  or  the  OHMIS  position  type 
code(s)  (CT2)  of  the  type(s)  of  persons  who  are  to  be  allowed 
to  perform  this  type  of  task.  This  identifies  the  type  of 
OHMIS  user/position  who  are  considered  to  be  “qual ifiable 
(potential ly  qualified)”  to  perform  this  type  of  task.  This 
field  may  be  left  blank  if  there  are  no  specifications  of  the 
type  of  user/position  to  which  the  person  performing  this  task 
must  belong. 

12.  Description  of  the  qualifications  for  performing  this  type  of 
task,  if  any.  May  refer  to  document  identifiers  (ID3)  giving 
more  information  about  the  qualifications  required,  if  any,  to 
perform  this  type  of  task. 

The  data  on  qualifications  for  the  task  type  given  in  the 
above  3  fields  is  used  to  identify  the  employee  identifiers 
(ID4)  for  the  OHMIS  users/positions  who  are  qualified  for  the 
task.  Once  it  is  determined  that  a  user/position  is 


DATA  SET  23 


qualified,  the  employee  identifier  (ID4)  for  the  user/position 
is  placed  on  the  DL34  list,  (i.e.,  the  list  of  qualified 
employee  identifiers  (ID4)  by  task  type  code  (CT8)  and  by 
OHMIS  service  area),  using  Menu  Selection  Sequence  7.5.1. 

Menu  Selection  Sequence  7.5.1  for  DL34  data  checks  to 
determine  that  the  OHMIS  user  identifier  (ID13)  or  position 
identifier  (ID14)  for  the  employee  identifier  (1D4)  entered 
onto  the  list  is  consistent  with  the  OHMIS  user/position  types 
(CT1/CT2),  if  any,  that  are  given  above  in  the  DS23  data  for 
the  type  of  persons  that  are  to  be  allowed  to  perform  this 
task. 

13.  Whether  this  is  a  'employee  transport1  type  of  task. 

Answer:  Yes/No.  Employee  transport  type  tasks  are  those  that 
require  taking  the  employee  away  from  his/her  work  site  to 
perform  the  task.  An  example  of  such  a  task  would  be  most 
medical  examinations.  Gn  the  other  hand,  the  task  of 
observing  an  employee  in  the  work  place  (e.g.,  to  see  if  the 
personal  protective  equipment  assigned  to  the  employee  is 
being  used  correctly)  would  not  be  an  employee  transport  type 
of  task.  The  reason  for  identifying  this  characteristic  of 
the  task  is  that  employee  transport  types  of  tasks  have  higher 
priority  in  scheduling;  the  OHMIS  scheduling  program  (Function 
F4)  is  designed  to  schedule  as  many  employee  transport  tasks 
for  a  given  employee  at  one  time  (to  the  degree  possible)  and 
to  avoid  rescheduling  such  tasks  to  the  degree  possible. 

14.  Whether  the  scheduling  of  this  type  of  task  should  trigger 
the  generation  of  a  Scheduling  Notice  (015).  Answer: 

Yes/No.  In  general,  a  Scheduling  Notice  is  needed  for  a  task 
if  performance  of  the  task  requires  that  a  participant  in  the 
task  come  to  a  specific  location  or  be  at  a  specific  location 
at  a  certain  time.  Medical  examinations  are  a  good  example. 
All  'employee  transport'  type  tasks  will  require  Scheduling 
Notices,  but  other  tasks  may  as  well. 

15.  To  which  person  is  the  Scheduling  Notice  (015)  to  be  sent. 
Answers  include:  1)  The  employee  identifier  (ID4)  that  is  one 
of  the  requirement  implementation  units  for  the  task;  or,  2) 
The  point  of  contact  given  in  the  contact  and  location  data 
(DS28)  on  the  employee,  job  class,  facility  and/or 
organizational  unit  that  is  one  of  the  requirement 
implementation  units  for  the  task.  More  than  one  answer  is 
possible. 
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Specific  Task  Scheduling  Data 


This  data  describes  a  particular  specific  task  (as  distinguished  from 
a  type  of  task  as  described  in  DS23  data)  that  has  been  scheduled 
(or  for  which  an  attempt  has  been  made  to  schedule  the  task)  by  the 
OHMIS  scheduling  program  (Function  F4).  This  data  is  generated  by  the 
OHMIS  program  (Function  F4)  whenever  a  set  of  requirements  implementa¬ 
tion  data  (DS5)  that  is  for  an  action  requiring  scheduling  is  generated, 
i.e.,  whenever  a  set  of  DS5  data  is  generated  for  a  requirement  for 
which  the  requirement  description  data  (DS1)  contains  a  task  type  code 
(CT8).  The  DS5  data  indicates  that  a  requirement  has  been  triggered, 
i.e.,  the  user  is  being  asked  to  perform  a  certain  required  (or  recom¬ 
mended)  action.  If  this  action  is  the  type  that  requires  scheduling 
(e.g.,  a  task  such  as  conducting  an  Industrial  Hygiene  survey),  the  task 
type  code  (CT8)  for  this  action  require  scheduling  is  given  on  the 
requirements  description  data  (DS1).  Therefore,  the  generation  of  DS5 
data  for  actions  requiring  scheduling  automatically  results  in  the  OHMIS 
program  scheduling  a  task  of  the  task  type  (CT8)  specified  in  the  DS1 
data  (as  a  part  of  Function  F4).  The  information  about  the  scheduling 
of  the  particular  task  that  is  to  be  executed  as  a  result  of  this 
triggered  requirement  is  given  in  DS24  data. 

Many  of  the  data  elements  on  the  DS24  data  are  used  to  determine  the 
priority  of  the  task  so  that  it  can  be  scheduled  accordingly.  For 
example,  tasks  for  requirements  that  are  mandatory  are  given  higher 
priority  in  the  scheduling  program  (Function  F4)  than  those  for 
recommended  requirements.  Also,  much  of  the  information  on  the  DS24 
data  is  used  to  group  like  tasks  together  in  scheduling.  Specifically, 
it  is  desirable  to  group  tasks  being  conducted  in  the  same  facility  or 
being  for  requirements  having  the  same  requirements  implementation  unit 
identifiers  together  when  scheduling.  The  DS24  data  on  the  facility  in 
which  the  task  is  to  take  place  and  on  the  requirement  implementation 
unit  for  the  requirement  that  triggered  the  task  is  used  in  order  to 
facilitate  the  grouping  together  of  tasks  according  to  these  factors. 

For  example,  the  ordering  of  a  new  type  of  hazardous  substance  by  an 
organizational  unit  will  probably  be  set  up  by  OHMIS  users  to  trigger  a 
requirement  for  investigating  and  developing  corrective  actions  for  this 
new  hazardous  substance  for  this  organizational  unit.  In  this  case,  the 
organizational  unit  identifier  (ID12)  is  a  requirement  implementation 
unit.  It  is  obviously  desirable  to  do  all  other  investigations  of 
hazardous  substances  for  this  organizational  unit  (ID12)  at  the  same 
time  or,  if  that  is  not  possible,  to  at  least  do  ail  other  tasks 
involving  this  organizational  unit  at  the  same  time  as  this  task. 

Another  example  of  the  need  to  group  tasks  together  when  scheduling 
would  be  for  what  are  called  'employee  transport'  tasks,  i.e,  tasks 
which  require  that  an  employee  be  taken  away  from  his  regular  work  site 
to  participate  in  the  task.  If  an  employee  were  scheduled  for  a  medical 
visit  to  the  Occupational  Health  Nurse  (an  employee  transport  type  of 
task)  for  more  than  one  requirement  (e.g.,  to  follow-up  on  a  corrective 
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action  and  to  conduct  a  routine  physical)  or  for  more  than  one  one  time 
during  a  quarter,  it  would  be  cumbersome  and  impractical  to  schedule  the 
employee  for  separate  Occupational  Health  Nurse  visits  for  each  task. 

To  avoid  this,  the  OHMIS  scheduling  program  (Function  F4A)  "looks  ahead" 
on  upcoming  requirements  for  the  employee,  using  the  list  of  requirement 
application  identifiers  (ID5)  for  requirements  suspense  data  (DS4)  by 
requirement  implementation  unit  identifiers  and  OHMIS  service  area 
identifiers  (DL32).  An  attempt  is  made  to  schedule  the  tasks  for  these 
requirements  (i.e.,  requirements  involving  tasks  that  are  employee 
transport  tasks  for  the  same  employee)  earlier  than  they  would  have  been 
scheduled  in  order  to  group  all  requirements  for  the  same  employee 
together. 

The  user  does  not  directly  generate  DS24  data;  it  is  generated  by  the 
OHMIS  program  following  the  generation  of  DS5  data.  If  the  user  wishes 
to  initiate  the  scheduling  of  a  particular  task,  the  user  would  input 
requirements  suspense  data  (0S4)  describing  the  task  that  is  to  be 
scheduled  and  the  date  the  task  is  due.  When  this  date  (minus  the 
'prior  notification  time1)  arrives,  the  OHMIS  program  (Function  FIA) 
will  generate  a  set  of  DS5  data  for  the  action  and  this  will,  in  turn, 
result  in  the  scheduling  of  the  action.  The  user  may  change  selected 
items  of  the  DS24  data  using  Menu  Selection  Sequence  7.4.1. 

DS24  data  is  deleted  when  the  user  enters  data  indicating  that  the 
requirement  for  which  the  task  was  triggered  has  been  executed,  i.e, 
when  the  user  enters  requirements  disposition  data  in  Menu  Selection 
Sequence  1.5.3  (Function  F2B).  The  user  is  not  allowed  to  directly 
delete  a  task,  because  deletion  of  a  task  constitutes  execution  of  the 
requirement  which  triggered  the  task  and  it  is  desired  that  this 
execution  of  requirements  be  documented  in  the  disposition  data  for  the 
requirement  on  the  requirements  implementation  data  (DS5)  for  the 
requirement.  That  is,  the  OHMIS  program  is  designed  to  stipulate  that  a 
formal  and  documented  decision  be  made  to  indicate  that  a  requirement 
has  been  executed;  therefore,  the  cancelling  process  of  deleting  a 
requirement  in  an  undocumented  way  by  deleting  the  task  associated  with 
the  requirement  from  the  schedule,  is  a  data  processing  function  not 
provided  for  in  OHMIS.  As  a  part  of  the  'log-on'  transparent  functions 
(Function  1A),  the  OHMIS  program  checks  daily  whether  more  than  one  week 
has  past  since  the  date  that  a  task  was  scheduled.  For  any  tasks  for 
which  this  is  the  case,  the  program  determines  whether  the  DS24  data  for 
the  task  has  been  deleted  (i.e.,  the  requirement  has  been  executed,  and, 
if  not,  reschedules  the  task). 

1.  Task  identifier  (ID23).  A  unique  identifier  assigned  by  the 
program  to  distinguish  this  set  of  DS24  data. 

2.  Date  that  this  data  generated,  i.e.,  date  that  the 
generation  of  requirements  implementation  data  (DS5)  triggered 
this  task.  This  date  is  included  on  the  Daily  Schedule  (014) 
in  order  that  the  user  may  know  for  what  length  of  time  the 
task  has  been  required.  This  is  especially  important  for 
undated  tasks  (i.e,  tasks  without  any  due  date),  because  these 
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tasks  have  very  low  priority  in  the  scheduling  program  and  may 
be  "bumped"  several  times  before  they  are  finally  scheduled. 

It  is  important  for  the  user  to  note  how  long  a  time  it  is 
taking  for  an  undated  task  to  be  executed  as  this  may  indicate 
a  scheduling  problem  for  the  OH MIS  service  area. 

3.  OHMIS  service  area  identifier  (ID10)  for  the  area  in  which 

this  task  was  generated.  From  the  requirements  implementation 
data  (DS5)  corresponding  to  the  requirement  implementation 
identifier  ( ID9)  given  below. 


4. 


Task  type  code  (CT8).  Obtained  from  the  DSl 
the  0S4  data  in  the  case  of  nonrequirement. 
Notice,  Suspense  Data).  Links  the  DS24  data 
description  data  (DS23)  which  provides  gener 
about  this  type  of  task. 


ta  (or  from 
,  Reminder 
the  task  type 
'^Grmation 


5.  Supplement  to  the  detailed  description  of  the  task.  This  is 
a  narrative  description  giving  further  information  about  this 
specific  execution  of  the  task.  Completion  of  this  data 
element  is  not  required.  If  the  user  desires  to  enter  this 
information,  it  is  done  as  a  part  of  changing  the  DS24  data 
(Menu  Selection  Sequence  7.4.1). 

6.  Supplement  to  the  description  of  the  task  given  on  the 
Scheduling  Notice  (015).  This  provides  additional  informa¬ 
tion,  beyond  that  provided  in  the  DS23  data.  This  information 
is  entered  in  Menu  Selection  Sequence  7.4.1.  The  OHMIS 
program  will  automatically  generate  a  Scheduling  Notice  when¬ 
ever  a  task  is  scheduled  that  has  been  identified  in  the  DS23 
data  as  requiring  a  Scheduling  Notice.  It  is  anticipated  that 
the  user  (e.g.,  the  Occupational  Health  Nurse)  will  examine 
each  Scheduling  Notice  before  it  is  sent  and  determine  if 
there  is  any  additional  information  needed  that  should  be 
placed  on  this  Notice.  If  there  is,  this  additional 
information  would  be  provided  through  making  changes  to  the 
0S24  data  (Menu  Selection  Sequence  7.4.1). 


7.  Supplement  to  the  description  given  to  a  participant  in  the 
task  (e.g.,  the  employee  being  scheduled  for  a  medical  exam) 
on  how  to  prepare  for  the  task.  An  example  would  be  "Do  not 
eat  breakfast  on  the  morning  of  the  test."  This  information 
is  in  addition  to  the  special  instructions  given  on  the  DS23 
data  to  a  participant  in  this  type  of  task.  Entered  in  Menu 
Selection  Sequence  7.4.1. 

8.  Supplement  to  the  description  of  the  preparation  for  this 
task  beyond  that  given  in  the  DS23  data.  Entered  in  Menu 
Selection  Sequence  7.4.1. 

9.  Time  use  code  (CT11)  for  the  task.  From  the  task  type 
description  data  (DS23)  corresponding  to  the  above  task  type 
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code  (CT8);  or  the  user  can  change  this  code  using  Menu 
Selection  Sequence  7.4.1. 

10.  Facility  identifier  (ID8)  for  the  location  in  which  the  task 
is  to  take  place.  This  information  is  provided  in  order  to 
enable  scheduling  of  tasks  that  are  to  take  place  in  the  same 
locations  at  similar  times.  The  ID8  may  be  derived  from  the 
facility  data  by  task  type  (DS25)  for  the  task  type  code  (CT8) 
specified  above.  This  facility  can  be  specified  in  a  generic 
way  in  the  DS25  data  because  certain  tasks  (e.g.,  an  Occupa¬ 
tional  Health  Nurse  medical  test)  will  always  be  conducted  in 
the  same  location  and  there  will  only  be  one  location  for 
conducting  the  task  for  a  given  OHMIS  service  area.  If  the 
ID8  is  not  available  on  the  DS25  data,  it  may  be  one  of  the 
requirement  implementation  unit  identifiers  for  the  task;  or, 
if  there  is  no  ID8  included  among  the  requirement  implementa¬ 
tion  unit  identifiers,  the  108  may  be  obtained  from  the 
contact  and  location  data  (DS28)  on  the  employee,  job  class, 
or  organizational  unit  that  is  ore  of  the  requirement 
implementation  unit  identifiers.  If  none  of  these  three  types 
of  identifiers  are  included  as  requirement  implementation 
units,  then  the  ID8  in  this  field  cannot  be  determined 
automatically  and  is  left  blank.  The  user  may  add  in  or 
change  the  ID8  for  the  main  facility  in  which  the  task  is  to 
be  conducted  using  Menu  Selection  Sequence  7.4.1. 

11.  Requirement  implementation  identifier  ( ID9 )  fo~  the 
requirement  implementation  data  (DS5)  which  triggered  the 
generation  and  scheduling  of  this  task. 

12 .  Identifiers  for  the  up  to  5  requirement  implementation  units 
for  this  task.  From  the  requirement  implementation  data  (DS5) 
corresponding  to  the  above  requirement  implementation 
identifier  (109). 

13.  Due  date,  if  any,  when  this  task  is  to  be  completed.  This 
date  comes  from  one  of  two  places,  either:  1)  if  the  DS5  data 
corresponding  to  the  abov^  ID9  was  triggered  by  a  requirement 
suspense  type  of  requirements  appl icabi 1 i ty  data  (i.e., 
triggered  by  0S4  data),  the  due  date  would  be  'next  suspense 
date',  plus  the  'prior  notification  time’  given  on  the  DS4 
data.  If  the  0S5  data  was  triggered  by  either  DS 3  data 
(information  triggered  requirements)  or  DS17  data  (allowable 
limits  triggered  requirements) ,  the  due  date  would  be  the 
current  date  plus  the  amount  of  time  allowed  to  complete  this 
type  of  task  as  specified  in  the  task  type  description  data 

( US 23 ) ,  if  any  has  been  specified.  Note  that  the  due  date  for 
the  task  need  not  be  the  same  for  the  requirement  which 
triggered  the  task,  because  the  requirement  may  involve  more 
than  completing  the  task. 
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14.  Whether  or  not  this  task  is  for  a  mandatory  or  for  a 
recommended  requirement.  From  the  requirement  description 
data  (DS1)  corresponding  to  the  requirement  identifier  (ID6) 
on  the  DS5  data  corresponding  to  the  above  ID9.  Used  to 
determine  the  priority  of  the  task,  when  scheduling  the  task. 

15.  Whether  or  not  this  task  was  generated  by  requirement  type 
suspense  data  (DS4)  or  Reminder  Notice  type  suspense  data. 

This  information  is  on  the  DS5  data  from  which  this  task  was 
triggered.  This  information  is  used  to  determine  the  priority 
of  the  task,  when  scheduling  it. 

16.  Standard  number  of  time  slots  (quarter  hour  periods)  required 
to  complete  this  task.  From  the  DS23  data  corresponding  to 
the  above  task  type  code  (CT8). 

17.  User  specified  number  of  time  slots  required  to  complete  this 
task.  This  is  the  same  as  the  standard  number  of  time 
slots  required,  if  no  specifications  have  been  made  by  the 
user.  The  user  would  make  this  specification  using  Menu 
Selection  Sequence  7.4.1  (changes  to  the  DS24  data).  Such 
specifications  would  be  made  if  the  user  felt  that  the 
standard  amount  of  time  allowed  to  complete  this  type  of 
task  (as  specified  in  the  DS23  data)  was  not  correct  for  this 
particular  execution  of  this  type  of  task.  Also,  if  the  task 
had  been  scheduled,  but  only  partial ly  completed  during  the 
scheduled  time  period,  the  user  would  place  an  estimate  of  the 
time  left  needed  to  complete  the  task  in  this  field,  so  that 
this  value  could  be  used  in  rescheduling  the  task  (i.e., 
scheduling  a  time  to  complete  what  is  left  of  the  task), 
rather  than  the  total  time  needed  to  complete  the  task.  The 
OHMIS  program  uses  the  user  specified  required  time  slots 

for  scheduling  tasks.  This  value  may  be  changed  several  times 
by  the  user  before  the  task  is  fully  completed. 

18.  Actual  number  of  time  slots  scheduled  for  this  task, 
including  extra  time  slots  required  for  interruptions. 

19.  Whether  the  user  specified  the  schedule  for  this  task. 

Answers:  Yes/No.  The  OHMIS  scheduling  program  (Function  F4A) 
schedules  tasks  'automatically*.  However,  the  user  can  change 
the  automatically  determined  schedule  for  a  task  by  specifying 
the  particular  time  slots  for  which  the  user  wants  the  tasks 
scheduled.  This  done  by  changing  the  DS24  data  using  Menu 
Selection  Sequence  7.4.1.  This  change  in  scheduling  may  be 
done  to  accommodate  a  particular  user  who  is  to  conduct  the 
task  or  to  accommodate  restrictions  on  scheduling  the  task 
arising  from  the  acceptable  time  periods  for  the  task  for  a 
participant  in  the  task  (e.g.,  the  time  the  employee  in  a 
medical  surveillance  task  has  available).  If  the  user 
specifies  a  time  for  scheduling  a  task,  this  schedule  is  given 
higher  priority  (i.e.,  is  not  as  easily  rescheduled)  as  those 
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that  are  automatically  scheduled.  Therefore,  it  is  important 
to  note  whether  the  schedule  for  the  task  was  specified  by  the 
user. 


20. 


Whether  there  are  any  restrictions  on  the  time  slots  in  which 
this  task  can  be  scheduled.  Answers:  Yes/No.  Examples  of 
such  restrictions  would  be  the  fact  that  the  employee 


scheduled  to  participate  in  the  task  (e.g.,  scheduled  for  a 
medical  exam)  regularly  works  the  swing  shift  or  that  the 
employee  is  going  to  be  on  leave  between  such  and  such 
dates. Also,  there  may  be  restrictions  on  the  times  when  it  is 


possible  to  enter  a  facility  (e.g.,  for  tasks  involving 
surveys  of  a  facility). 


There  are  two  types  of  restrictions,  referred  to  as  standard 
restrictions  and  special  restrictions.  Standard 
restrictions  are  restrictions  that  "always"  apply  for  the 
employee,  facility,  job  class  or  organizational  unit  involved 
in  the  task.  Restrictions  due  to  the  regular  working  hours  or 
shifts  of  the  employee  or  the  hours  in  which  a  facility  is 
regularly  open  would  be  typical  examples  of  standard 
restrictions.  The  standard  restrictions,  if  any,  for  an 
employee,  facility,  job  class  or  organizational  unit  are  given 
on  the  contact  and  location  data  (DS28)  for  the  employee, 
facility,  job  class  or  organizational  unit  by  identifying  a 
set  of  weekly  schedule  data  (DS26)  containing  the  standard 
restrictions.  The  weekly  schedule  identified  (ID28)  for  this 
set  of  DS26  data  is  entered  onto  the  DS24  data  when  the  DS24 
data  is  generated. 


Special  restrictions  are  those  that  are  peculiar  to  the 
particular  task  or  that  arise  from  non-routine  situations. 

The  finding  that  an  employee  will  be  on  leave  for  a  given  time 
period,  and,  therefore,  it  is  not  acceptable  to  schedule  the 
employee  during  that  time  period,  would  be  an  example  of  a 
special  restriction  for  scheduling  a  task.  Special 
restrictions  are  given  on  the  DS24  data  for  the  task.  The 
user  may  enter  special  restrictions  as  a  part  of  changing  the 
DS24  data  (Menu  Selection  7.4.1).  Information  about  the 
special  restrictions  may  be  obtained  from  the  information 
given  at  the  bottom  of  a  Scheduling  Notice  (015).  The  bottom 
portion  of  a  Scheduling  Notice  allows  the  person  being 
notified  of  the  task  (i.e.,  the  participant)  to  indicate  that 
the  time  scheduled  for  the  task  is  not  acceptable  and  to  give 
the  other  times  on  which  the  task  cannot  be  scheduled  (i.e., 
the  restrictions)  or  a  preferred  time  slot. 


21.  Three  sets  of  from/to  dates  for  the  times  that  the  task  cannot 
be  scheduled,  i.e.,  restricted  dates,  if  any.  This 
information  is  a  part  of  the  special  restrictions  data 
described  above.  The  sets  of  dates  are  given  in  the  format  of 
ranges,  that  is:  equal  to  X,  greater  than  X  and  less  than  Y, 
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less  than  X  and  greater  than  Y,  less  than  X  and  greater  than  Y 
(where  ‘ X '  and  ' Y *  are  dates  and  'less  than'  means  before  and 
'greater  than'  means  after  the  date.)  Changes  in  the 
restricted  dates  may  be  made  by  changing  the  DS24  data  (Menu 
Selection  Sequence  7.4.1);  such  changes  may  result  in 
rescheduling  (Function  F4B). 

22.  Weekly  schedule  identifier  (ID28)  for  the  weekly  schedule 
indicating  the  times  during  the  week  that  this  task  cannot 
be  scheduled,  i.e.,  the  standard  restricted  times  (as 
distinguished  from  special  restricted  dates).  TFe  DS28  for 
the  employee,  facility,  job  class  or  organizational  unit 
participating  in  this  task  provides  the  weekly  schedule 
identifier  (ID28)  for  the  task,  if  any.  The  standard 
restricted  times  are  shown  on  the  weekly  schedule  data  (DS26) 
corresponding  to  the  ID28.  If  there  are  no  restricted  times 
(either  because  there  is  no  DS28  data  on  the  participant  in 
the  task  or  because  the  DS28  data  does  not  specify  an  ID28), 
this  field  is  left  blank.  Changes  in  the  weekly  schedule 
identifier  (ID28)  are  made  by  changing  or  adding  the  DS28  data 
for  the  participant  in  the  task;  such  changes  may  result  in 
rescheduling  of  the  task  (Function  F4B) . 

23.  Whether  this  task  is  currently  scheduled  and,  if  not,  why 
not.  The  OHMIS  scheduling  program  (Function  F4A)  will 
automatically  schedule  a  task  as  soon  as  the  requirement 
implementation  data  (DS5)  for  the  task  is  generated,  i.e.,  a 
requirement  is  triggered  as  soon  as  the  next  program  'log  on' 
sequence  (Function  1A)  is  begun.  However,  there  are  two 
reasons  why  it  may  not  be  possible  to  schedule  a  task:  1)  the 
OHMIS  service  area  in  which  the  task  is  to  be  completed  (i.e., 
in  which  the  DS5  data  originated)  does  not  currently  have  any 
regular  weekly  scheduled  availability  data  (DS26),  i.e.,  there 
is  not  data  to  indicate  that  there  are  any  users/positions 
with  time  available  for  scheduling  in  the  OHMIS  service  area. 
This  is  not  likely  to  happen,  except  during  the  start-up 
phases  of  the  OHMIS  system;  2)  there  are  no  users/positions  in 
the  OHMIS  service  area  that  have  been  listed  as  qualified  to 
perform  tasks  of  this  type.  The  list  of  qualified  employee 
identifiers  (104)  by  task  type  (CT8)  and  by  OHMIS  service  area 
(DL34)  indicates  which  persons  in  an  OHMIS  service  area  are 
qualified  to  perform  a  task  of  a  given  type.  If  there  is  no 
such  person  in  the  OHMIS  service  area  for  this  task,  then  it 
will  not  be  possible  to  schedule  the  task. 

This  field  indicates  whether  or  not  the  task  was  scheduled 
and,  if  not,  why  in  order  that  the  task  can  be  listed  on  the 
List  of  Unscheduled  Tasks  (017).  Explanations  for  why  it  was 
not  possible  to  schedule  the  task  will  be  given  in  the  form  of 
codes,  indicating:  A)  there  are  no  qualified  persons  to 
perform  the  task  in  this  OHMIS  service  area,  or  B)  the  quali¬ 
fied  persons  do  not  have  any  DS26  data  for  them.  If  code  ' B' 
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is  used,  the  identify  of  the  qualified  persons  for  which  there 
are  no  DS26  data  sets  would  be  given.  It  is  possible  that  the 
reason  the  task  is  not  scheduled  is  because  it  was  necessary 
to  reschedule  the  task.  If  so,  a  code  of  1 C'  would  be 
entered.  A  code  of  *  D'  would  indicate  no  attempt  has  yet  been 
made  to  schedule  this  task. 

The  task  identifier  (ID23)  for  all  tasks  that  cannot  be 
scheduled  goes  on  the  list  of  tasks  that  cannot  be  scheduled 
(DL31)  or,  the  list  of  tasks  that  need  to  be  rescheduled 
(DL39)  to  await  further  information.  Each  day  the  OHMIS 
'log-on'  transparent  function  program  (Function  F1A) 
identifies  the  current  tasks  on  the  DL31  and  DL39  lists  (and 
the  list  of  requirement  implementation  identifiers  (ID9)  for 
tasks  for  which  there  has  been  no  attempt  to  schedule  the 
task)  and  'sends'  these  lists  to  Function  F4A  which  attempts 
to  schedule  these  tasks  before  the  Daily  Schedule  (014)  and 
the  List  of  Unscheduled  Tasks  (017)  is  generated  for  that  day. 
That  is,  each  day  in  the  Function  F4A,  the  OHMIS  program 
determines  whether  the  user  has  entered  the  data  needed  to 
schedule  an  unscheduled  task  and,  if  so,  schedules  it. 

Too  many  instances  of  not  being  able  to  automatically  schedule 
a  task  is  an  indication  of  a  scheduling  problem.  The  problem 
may  be  that  the  mix  of  qualified  personnel  in  an  OHMIS  service 
area  is  not  consistent  with  the  mix  of  tasks  required  for  that 
service  area.  It  is  expected  that  each  OHMIS  service  area 
will  review  the  List  of  Unscheduled  Tasks  (017)  periodically 
and  determine  if  the  number  of  unscheduled  tasks  is  routinely 
excessive;  attempts  to  correct  the  scheduling  problem  would 
then  be  made,  if  necessary. 

24.  Time  slot  information  for  the  time  at  which  this  task  is 
scheduled  to  begin.  Time  slot  information  consists  of  the 
monthly  schedule  identifier  (ID27)  and  the  date  and  quarter 
hour  during  the  day  (i.e.,  the  time  slot  number  from  '1' 
through  '96'  indicating  the  quarter  of  an  hour  of  the  day) 
during  which  this  task  is  scheduled  to  start.  The  monthly 
schedule  identifier  (ID27)  identifies  the  monthly  schedule 
data  (DS27)  that  contains  the  user/position  scheduled  to 
perform  the  task  and  the  year  and  month  in  which  the  task  is 
to  be  performed.  The  time  slot  information  is  added  to  the 
DS24  data  once  the  task  is  scheduled  by  the  OHMIS  scheduling 
program  (Function  F4A);  at  that  time  it  is  placed  on  both  the 
monthly  schedule  data  (DS27)  covering  all  tasks  for  a 
user/position  for  a  month  and  on  the  DS24  data  covering  a 
specific  task.  The  OHMIS  user  identifier  (ID13)  or  position 
identifier  (ID14)  and  employee  identifier  (ID4)  of  the  person 
scheduled  to  perform  this  task  is  given  on  the  DS27  data 
referenced  by  the  ID27  given  in  this  field.  This  identifier 
must  be  on  the  list  of  qualified  employee  identifiers  (ID4)  by 
task  type  (DL34).  The  user  may  change  the  ID27  and  task  start 
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time  (i.e.,  specify  his  own  schedule)  for  the  task  using  Menu 
Selection  Sequence  7.4.1.  This  will  result  in  a  rescheduling 
of  the  task  (Function  F4B). 

25.  Time  slot  information  (ID27  plus  date  and  time  slot  number) 
for  which  this  task  is  scheduled  to  be  completed,  i.e.,  the 
end  time  for  the  task. 

26.  The  number  of  interruptions  in  this  task  as  it  is  currently 
scheduled,  i.e.,  the  number  of  times  the  task  is  scheduled  to 
start  but  work  on  the  task  is  scheduled  to  end  before 
completion  of  the  task  because  of  a  break  for  the  end  of  a 
day,  for  a  lunch  period,  for  another  task,  etc.  Answer  may  be 
'O'.  The  OHMIS  scheduling  program  attempts  to  optimize  the 
schedules  for  tasks  to  reduce  the  number  of  interruptions  in 
the  task.  If  interruptions  are  necessary,  the  program  adds 
one  time  slot  (quarter  of  an  hour  period)  to  the  time  required 
to  complete  the  task  for  each  interruption. 

27.  Whether  this  task  is  scheduled  to  be  completed  after  the 
due  date  for  the  task.  The  OHMIS  scheduling  program  is 
designed  to  maximize  the  number  of  tasks  that  are  completed 
before  the  due  date.  However,  if  there  are  more  dated  tasks 
(i.e,  tasks  with  due  dates)  then  there  are  hours  available 
for  scheduling,  the  program  will  schedule  the  next  task  to 
start  as  close  to  the  due  date  as  possible.  If  the  task  is 
scheduled  to  be  completed  after  the  due  date,  this  is  noted 
in  this  field  on  the  DS24  data  so  that  the  user  can  be 
alerted  to  this  scheduling  problem  on  the  Scheduled  Task 
Description  (016)  output.  If  any  tasks  for  an  OHMIS  service 
area  are  found  to  be  scheduled  after  the  due  date,  this  is 
an  indication  of  a  scheduling  problem.  There  may  not  be 
enough  hours  available  for  scheduling  for  a  given  OHMIS 
service  area  or  it  is  possible  that  the  hours  required  for 
completing  the  tasks  are  too  great  compared  to  the  hours 
available  for  scheduling.  Another  problem  may  be  that  the 
'prior  notification  time'  given  on  the  suspense  requirements 
data  (DS4)  is  frequently  too  short  a  time  so  that  tasks  are 
not  being  scheduled  sufficiently  ahead  of  time  that  they  are 
due  to  enable  their  scheduling  before  the  due  date. 

Not  all  tasks  have  a  due  date.  The  only  dated  tasks  are  those 
triggered  by  the  generation  of  requirements  implementation 
data  (DS5)  that  was  triggered  by  0S4  data,  i.e.,  tasks  for 
date  triggered  requirements;  or,  tasks  for  which  a  length  of 
time  to  complete  the  task  has  been  specified  in  the  DS23  data. 

28.  Whether  all  of  the  time  slots  scheduled  for  the  task  were 
scheduled  at  the  preferred  time  use.  Answers:  Yes/No.  The 
OHMIS  scheduling  program  is  designed  to  maximize  the  degree  to 
which  each  OHMIS  user  is  scheduled  for  tasks  involving  a  given 
time  use  at  the  time  tnat  the  user  preferred  to  be  scheduled 
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for  tasks  involving  this  time  use.  However,  there  are  three 
reasons  why  this  may  not  always  be  possible.  The  scheduling 
program  may  override  the  user's  preferred  time  use  (i.e., 
schedule  an  available  time  slot  for  a  different  use  than  that 
preferred  by  the  user)  if:  1)  this  is  necessary  in  order  to 
schedule  a  task  to  be  completed  before  its  due  date;  or,  2)  if 
the  OHMIS  service  area  does  not  have  any  user  with  a  regular 
weekly  schedule  availability  data  (DS26)  that  includes  the 
type  of  time  use  involved  in  the  task  being  scheduled;  or,  3) 
if  scheduling  the  task  according  to  the  user's  preferred  time 
use  would  mean  that  there  were  excessive  breaks  in  the  time 
scheduled  for  tasks  for  that  user;  or  4)  if  not  overriding  the 
user's  preferred  time  use  would  make  it  impossible  to  schedule 
an  'employee  transport*  task  next  to  other  'employee 
transport'  tasks  for  the  same  employee.  Whether  the  user's 
preferred  time  use  was  overridden  is  indicated  in  this  field 
so  that  this  information  can  be  provided  to  the  user  on  the 
Scheduled  Task  Description  (016)  output  in  order  to  make  the 
user  aware  of  this  scheduling  problem.  Too  many  instances  of 
not  being  able  to  schedule  the  task  according  to  the  user's 
time  use  preference  indicates  a  scheduling  problem.  This 
scheduling  problem  may  result  when  the  mix  of  time  uses  for 
all  users  in  an  OHMIS  service  area  is  not  consistent  with 
the  actual  time  use  mix  required  to  complete  all  tasks  being 
triggered  for  that  OHMIS  service  area. 

29.  Whether  more  than  one  person  has  been  scheduled  to  perform 
this  task.  Answers:  Yes/No.  The  OHMIS  scheduling  program 
(Function  F4A)  only  allows  a  task  to  be  performed  by  one 
person,  i.e.,  a  task  is  not  divided  among  several  persons. 
However,  if  the  user  wishes  two  or  more  persons  to  perform  a 
task  at  the  same  time,  this  can  be  specified  by  the  user. 

This  would  be  done  for  those  tasks  that  require  more  than  one 
person  to  perform  them  and,  therefore,  requires  scheduling  two 
or  more  persons  to  perform  the  task  at  the  same  time.  The 
user  identifies  the  additional  person(s)  performing  the  task 
in  Step  F4B-7  and  the  program  fills  in  the  monthly  schedule 
data  (DS 27)  for  that  person  as  a  part  of  that  Step. 

30.  If  the  answer  to  the  above  question  was  'Yes',  up  to  3  sets  of 
the  following  data  elements  for  each  of  the  other  persons  also 
scheduled  to  perform  this  task: 

(1)  Employee  identifier  (ID4) 

(2)  OHMIS  user/position  identifier  (ID13/ID14)  of  the  above 
person 

(3)  Monthly  schedule  identifier  (ID27)  for  the  monthly 
schedule  data  (DS27)  on  which  this  person  is  scheduled  to 
start  performing  this  task 
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Facility  Data  By  Task  Type 


This  data  is  used  to  identify  the  location  in  which  tasks  are  to  be 
performed  in  a  given  OHMIS  service  area,  if  it  is  possible  to  know  this 
location  for  a  task  generically.  This  information  is  used  to  indicate 
the  location  of  a  task  (e.g.,  a  medical  exam)  on  the  Scheduling  Notice 
(015)  so  that  the  participant  in  the  tasks  may  know  where  to  report  for 
the  task.  It  is  also  used  in  the  OHMIS  automatically  scheduling  program 
(Function  F4)  to  provide  information  on  the  location  of  tasks  so  that 
tasks  that  are  to  be  conducted  in  the  same  location  can  be  scheduled 
together. 

The  DS25  data  provides  the  location  of  task  types,  i.e.,  the  generic 
location  in  which  all  tasks  of  a  given  type  are  to  be  conducted,  not  the 
location  of  a  specific  task.  It  will  not  always  be  possible  to  know  of 
the  location  of  a  task  type  or  for  there  to  only  one  location  for  a 
given  task  type,  but  if  it  is  possible  to  specify  this  one  location, 
this  information  is  provided  in  the  DS25  data.  This  data  is  entered  by 
the  user  using  Menu  Selection  Sequence  7.6.1.  This  data  may  be  deleted 
or  changed  at  any  time.  However,  at  any  point  in  time  there  can  only  be 
one  set  of  DS25  data  for  a  given  task  type  (CT8)  and  OHMIS  service  area. 
The  DS25  entry  program  will  check  for  this  upon  entry  of  DS25  data. 

1.  Task  type  code  (CT8)  for  which  this  data  describes  the 
location  at  which  tasks  of  this  type  are  to  take  place. 

2.  OHMIS  service  area  identifier  (ID10)  for  which  this  set  of 
DS2b  data  is  being  generated. 

3.  Time  use  code  (CT11)  for  this  type  of  task.  This  is 
supplied  from  the  task  type  description  data  (DS23). 

4.  Facility  type  code  (CT7)  at  which  tasks  of  this  type  are  to 
take  place.  Examples  of  facility  types  would  be  "Occupational 
Health  Nurse  station",  "hearing  clinic",  etc.  This  may  be 
left  blank  if  there  is  no  CT7  assigned  to  the  facility  or  if 
the  facility  at  which  this  type  of  task  is  to  be  completed 
will  only  be  defined  in  this  set  of  DS25  data  in  generic  terms 
(see  below). 

5.  Generic  description  of  facility.  This  field  is  given  as  an 
alternative  to  supplying  the  facility  type  code  (CT7)  and 
facility  identifier  (ID8)  (below)  when  the  exact  location  in 
which  the  task  type  is  to  be  performed  cannot  be 
determined,  but  it  can  be  described  generically.  Examples 
would  be:  "The  place  where  the  employee  reports  to  work". 

Such  loose  definitions  of  facility  types  are  used  in  the 
Scheduling  Notice  (015)  for  tasks  in  which  it  is  not  possible 
to  specify  the  exact  location  of  all  tasks  of  this  type. 
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because  specific  executions  of  tasks  of  this  type  will  be 
conducted  in  different  places,  but  for  which  it  is  possible  to 
describe  the  location  generically.  If  this  is  the  type  of 
location  information  being  given  in  this  DS25  data,  then  only 
this  field  (i.e.,  the  "generic  description  of  facility")  is 
provided  on  the  DS25  data,  i.e.,  no  CT7  facility  identifier 
(ID8)  or  facility  address  is  given. 

6.  Facility  identifier  (ID8)  for  the  facility  at  which  the  task 
will  take  place. 

7.  Complete  address  of  the  above  facility,  including  room 
number,  floor,  etc. 

8.  Narrative  description  of  any  additional  information  needed 
about  the  facility  to  instruct  persons  on  this  location,  e.g., 
directions,  passes  needed,  etc.  This  information  will  be 
included  on  the  Scheduling  Notice  (015)  in  order  to  enable 
this  Notice  to  be  used  to  instruct  the  employee  on  how  to 
arrive  at  the  proper  location  for  the  test  or  other  task  in 
which  the  employee  is  participating. 
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Regular  Weekly  Schedule  Availability  Data 


This  data,  like  the  monthly  schedule  data  (availability  and  use)  (DS27), 
identifies  the  hours  that  an  OHMIS  user/position  is  available  for 
scheduling  and  the  preferred  time  use  for  each  quarter  of  an  hour 
available  for  scheduling.  The  DS26  data  is  used  in  conjunction  with  the 
DS27  data  in  order  to  make  it  simple  for  the  user  to  enter  his/her  time 
availability  and  to  make  it  possible  to  generate  tentative  monthly 
schedule  data  (DS27)  without  input  from  the  user. 

The  OHMIS  program  allows  the  user  to  specify  his/her  regular  schedule 
(i.e.,  normal  work  periods  available  for  scheduling  without  regard  to 
special  situations  such  as  holidays  or  vacations)  on  a  weekly  basis  in 
the  DS26  data.  The  user  the  provides  any  variations  required  from  this 
regular  weekly  schedule,  such  as  exceptions  needed  for  holidays, 
sickness,  other  absences  of  leave,  etc.  by  making  changes  to  the  DS27 
data  that  is  generated  for  a  month  using  the  DS26  data.  Thus,  for 
example,  the  user  may  "normally"  be  available  for  scheduling  for  "in  the 
field"  tasks  (i.e.,  a  particular  time  use)  from  8:00  a.m.  to  12:00  p.m. 
on  Mondays.  This  the  user  would  show  on  a  set  of  DS26  data.  The  OHMIS 
scheduling  functions  program  (Functions  F4)  would  use  this  entry  on  the 
DS26  data  to  schedule  this  time  period  for  every  Monday  in  a  month  in 
the  time  use  specified  by  the  user.  If,  however,  on  a  particular 
Monday  (January  3,  1983)  the  user  will  not  be  available  during  this  time 
period  or  wishes  to  temporarily  change  the  time  use  code  for  this  time 
period,  the  user  would  indicate  this  by  changing  the  DS27  data  for  the 
month  containing  January  3,  1983.  Thus,  the  user  is  able  to  make 
temporary  changes  in  his  hours  available  for  scheduling  without  changing 
his  routine  schedule.  This  will  make  it  easier  for  the  user  to  keep  his 
normal  schedule  availability  data  up  to  date.  It  also  makes  it  possible 
for  the  OHMIS  scheduling  program  to  generate  tentative  DS27  data  (using 
the  DS26  data)  sowing  availability  on  a  monthly  basis  (in  Function  F4C) 
without  input  from  the  user  so  that  schedule  availability  data  may  be 
generated  at  any  time  that  it  is  needed  to  add  a  new  task  to  the  user's 
schedule. 

DS26  data  is  entered  by  the  user  during  Menu  Selection  Sequence  7.2.1. 

A  begin  date  and  end  date  are  olaced  on  the  DS26  data  to  indicate  when 
this  regular  weekly  availability  schedule  is  to  apply.  A  given 
user/position  may  only  have  one  set  of  DS26  data  covering  a  given  period 
of  time  at  a  time,  i.e.,  the  begin  and  end  dates  for  the  DS26  data  for 
the  same  user/position  must  not  overlap.  It  should  be  noted  that  the 
entry  of  DS26  data  on  an  employee  is  an  indication  that  this 
user/position  is  available  for  scheduling  of  OHMIS  tasks  by  the  OHMIS 
scheduling  program.  All  user/positions  for  which  it  is  desired  to  have 
the  OHMIS  scheduling  program  schedule  tasks  must  have  DS26  data. 
Similarly,  the  deletion  of  DS26  data  is  the  way  that  an  employee  is 
shown  to  be  no  longer  available  for  scheduling.  This  would  be  done,  for 
example,  if  the  employee  is  to  be  terminated.  To  avoid  having  the  OHMIS 
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scheduling  program  continue  to  schedule  tasks  for  an  employee  for  the 
time  between  the  date  when  the  employee's  termination  is  known  and  the 
actual  termination  data,  the  user  would  enter  an  end  date  on  the  DS26 
data  for  the  termination  date.  The  OHMIS  scheduling  program  would  know 
from  this  end  date  information  that  no  monthly  schedule  data  (DS27)  is 
to  be  generated  from  this  set  of  DS26  data  after  the  end  date  shown. 
Similarly,  the  user  can  achieve  having  the  OHMIS  scheduling  program 
schedule  tasks  for  user/positions  that  are  not  currently  available  in 
the  OHMIS  service  area,  but  who  will  be  available  by  a  known  date.  This 
is  achieved  by  inputting  a  set  of  DS26  data  with  a  start  date  for  the 
date  in  which  the  employee  will  be  available  for  scheduling.  The  use  of 
the  end  date  and  start  date  thus  makes  it  possible  to  ensure  that  the 
employee  is  scheduled  for  OHMIS  tasks  immediately  upon  availability  and 
not  scheduled  for  tasks  immediately  upon  knowledge  of  his/her  change  in 
availability  for  tasks. 

The  0S26  data  is  also  used  to  show  the  standard  weekly  restrictions  on 
scheduling  for  one  or  more  persons  or  things.  The  contact  and  location 
data  (DS 28)  for  an  individual  or  thing  (e.g.,  facility)  indicates 
whether  there  is  a  set  of  0S26  data  showing  the  availability  of  employee 
or  thing  to  participate  in  a  task  (as  distinguished  from  performing 
a  task).  Thus,  if  an  employee's  shift  meant  that  he  would  be  available 
(e.g.,  for  medical  examinations)  only  between  the  hours  of  8:00  p.m.  and 
4:30  a.m.,  Monday  through  Friday,  there  would  be  a  set  of  DS26  data 
showing  this  availability  information.  Because  more  than  one  employee 
may  have  the  same  restrictions  on  availability,  the  same  set  of  DS26 
data  is  used  to  show  availability  for  multiple  persons  and  things  (e.g., 
facilities);  the  weekly  schedule  identifier  (ID28)  on  the  DS28  data 
indicates  which  set  of  DS26  restrictions  data  applies  to  an  employee  or 
thing. 

The  OHMIS  program  (in  Function  F4C)  uses  DS26  data  to  generate  a 
tentative  monthly  schedule  (OS27  data)  for  the  user,  i.e.,  a  schedule 
without  any  holidays,  vacations,  special  monthly  exceptions,  etc. 
Whenever  the  DS26  data  is  changed  (Menu  Selection  Sequence  7.2.3)  or 
deactivated  (Menu  Selection  Sequence  7.2.2),  i.e.,  an  end  date  is 
supplied,  the  OHMIS  rescheduling  program  (Function  F4B)  makes  the 
necessary  adjustments  in  the  user's  monthly  schedule  data  (DS27)  for  all 
months  following  the  change  in  0S26  data. 

1.  Weekly  schedule  identifier  (ID28).  Unique  value  identifying 
this  set  of  DS26  data 

2.  Whether  this  is  a  set  of  DS26  data  used  to  show  restricted 
times.  See  the  contact  and  location  data  (DS28)  for  an 
explanation  of  this  use  of  DS26  data. 

3.  Employee  identifier  (ID4)  to  which  this  set  of  DS26  data 
es.  Left  blank  if  this  DS26  data  is  used 
icted  times  for  a  task. 


DATA  SET  26 


4.  The  OHMIS  user  identifier  (ID13)  or  position  identifier 

( ID14)  for  the  above  employee.  Left  blank,  if  no  employee. 

5.  OHMIS  service  area  identifier  ( I  DIO )  for  the  above  employee 
identifier  (ID4)  or  the  above  task  identifier  (ID23),  if  this 
is  a  restricted  times  type  of  DS26  data  set. 

6.  Start  date  for  this  DS26  data. 

7.  End  date  for  this  DS26  data.  May  be  left  blank. 

8.  Pay  of  the  week  (Monday  through  Sunday,  1-7). 

9.  For  each  day  of  the  week: 

9a)  Time  slot  number  (1  to  96)  for  each  day  of  the  week, 

there  are  96  time  slots  (one  for  each  quarter  of  an  hour 
period  in  a  day).  Thus,  2:15  p.m.  would  be  assigned  the 
time  slot  number  of  ‘58*. 

9b)  Whether  any  time  slots  in  the  day  are  available  for 
scheduling.  Answers:  Yes/No 

9c)  For  each  of  the  96  time  slots  in  a  day: 

i)  Whether  the  time  slot  is  available  for 

schedul inq.  Answer:  Yes/No.  Examples  of 
regular  time  not  available  for  scheduling  would 
not  only  be  lunch  hours  and  hours  not  on  the  job, 
but  also  hours  set  aside  for  handling 
nonscheduled  tasks,  e.g.,  processing  an 
injury/illness  report.  If  the  answer  to  9a)  was 
'No',  then  this  answer  must  be  ‘No*. 

Only  regular  schedule  availability  is  shown  on 
the  DS26  data,  i.e.,  the  schedule  that  the  user 
wishes  the  OHMIS  program  to  use  to  generate  a 
tentative  monthly  schedule  (0S27)  for  any  month 
in  the  future.  Changes  in  the  regular  weekly 
schedule,  unless  they  appear  to  be  the  type  that 
will  last  for  an  extended  period  of  time  (at 
least  two  months)  should  not  be  made  on  this 
data.  This  is  because  the  OHMIS  program  uses  the 
DS26  data  to  generate  monthly  schedules  of  DS27 
data  at  least  two  months  in  advance  (further  in 
advance  if  the  user  enters  advance  scheduling 
data  on  the  monthly  schedule  data  (DS27)). 
Exceptions  to  the  regular  time  available  for 
scheduling  are  indicated  by  making  changes  to  the 
0S27  data  (Menu  Selection  Sequence  7.3.1). 
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If  this  is  a  restricted  times  type  of  DS26  data 
set,  this  field  contains  the  answer  Yes/No  for 
whether  this  time  slot  is  restricted. 

ii)  For  each  of  the  96  time  slots  identified  above  as 
available  for  scheduling,  the  preferred  time  use 
code  (CT11) .  This  code  was  explained  in  the  task 
type  description  data  (DS23).  In  the  DS26  data  set, 
the  CT11  allows  the  user  to  specify  what  general 
types  of  tasks  are  to  be  scheduled  for  each  quarter 
of  an  hour  available  for  scheduling.  Left  blank  for 
restricted  times  type  of  DS26  data. 
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Monthly  Schedule  Data  (Availability  and  Use) 


This  data  describes  both  the  schedule  avai 1 abi 1 i ty  data  for  a  given 
month  and  user  and  the  actual  planned  use  of  the  hours  available  for 
scheduling  for  that  month  and  user  to  the  degree  that  they  are  known  as 
of  the  current  date.  Based  on  the  regular  weekly  schedule  availability 
data  (DS26)  provided  by  the  user,  the  OHMIS  program  generates  a 
tentative  availability  schedule  (DS27  data)  for  the  month  (Function 
F4C),  i.e.,  the  schedule  of  what  hours  the  user  has  available  for 
scheduling  tasks  and  what  the  user's  preferred  time  use  for  these  time 
slots  is.  The  user  may  modify  this  monthly  availability  data  on  the 
DS27  to  fit  the  particular  circumstances  of  the  month  (i.e.,  for 
variations  from  the  regular  weekly  schedule  shown  on  the  DS26  data) 
using  Menu  Selection  Sequence  7.3.2.  In  the  OHMIS  program  Function  F4A, 
specific  tasks  are  scheduled  (i.e.,  the  DS27  data  is  "filled  in")  to  fit 
the  availability  shown  on  the  DS27  data.  The  DS27  data  thus  shows  for 
any  given  month  the  time  available  and  the  time  already  scheduled  for 
the  OHMIS  user/position. 

The  DS27  data  is  generated  by  the  OHMIS  program  once  a  month  for  enough 
months  (i.e.,  0,  1  or  2  months)  to  ensure  that  there  is  DS27  data  for 
each  OHMIS  user/position  for  2  months  in  advance  using  the  DS26  data. 
(The  time  and  the  month  that  this  generation  of  DS27  data  takes  place  is 
arbitrary,  but  it  is  advisable  to  have  a  fixed  date  in  order  that  the 
users  may  be  informed  so  that  any  changes  in  the  regular  weekly  schedule 
data  (DS26)  can  be  made  before  the  DS27  data  is  generated.)  This 
routine  generation  of  DS27  data  is  triggered  as  a  part  of  Function  F1A, 
but  is  done  in  Function  F4C.  However,  it  may  not  be  necessary  to 
generate  any  new  DS27  data  at  this  routine  point  in  time,  because  this 
data  may  have  already  been  generated  by  the  OHMIS  program  as  a  part  of 
inputting  deletions  or  changes  to  the  monthly  schedule  data  (DS27) 
during  Function  F4B.  For  example,  if  the  user  wishes  to  enter  a 
vacation  schedule  4  months  in  advance  (using  Menu  Selection  Sequence 
7.3.2),  the  OHMIS  program  will  generate  a  monthly  schedule  data  (DS27) 
for  the  user  for  each  of  the  four  months  up  and  including  the  month  that 
the  user  wishes  to  enter  schedule  availability  changes  for.  Similarly, 
if,  in  the  process  of  scheduling  a  task,  all  of  the  time  availability 
for  all  users  for  a  given  time  period  has  already  been  scheduled,  the 
OHMIS  scheduling  program  (Function  F4A)  will  generate  additional  monthly 
schedule  data  (DS27)  for  as  many  months  into  the  future  as  is  necessary 
to  enable  scheduling  of  the  task.  Because  of  these  two  other  occasions 
in  which  DS27  data  is  generated,  it  may  not  be  necessary  to  generate  any 
DS27  data  for  a  user  at  the  routine  time  once  a  month,  i.e.,  as  a  part 
of  the  log  on  transparent  function  (Function  F1A). 

JS27  data  is  deleted  one  week  after  the  end  of  the  month  covered  by  the 
DS27  data.  Every  day,  as  a  part  of  the  log  on  transparent  function 
(Function  F1A)  the  OHMIS  program  will  examine  those  tasks  that  were 
scheduled  to  be  performed  on  the  date  one  week  previous  to  the  current 
date.  If  the  tasx  has  been  executed  (i.e.,  if  the  requirement 
disposition  data  on  the  requirement  that  generated  the  task  has  been 
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entered  using  Menu  Selection  Sequence  1.5.3;  Function  F2B)  and  therefore 
the  specific  task  scheduling  data  (DS24)  has  been  deleted  for  the  task, 
then  nothing  is  done.  If  not,  the  task  is  rescheduled.  When  the  tasks 
scheduled  for  the  last  day  of  the  month  have  been  examined  in  this  way 
(i.e.,  one  week  after  the  end  of  the  month)  and  all  tasks  that  have  not 
been  completed  have  been  rescheduled,  the  DS27  data  is  deleted. 

1.  Monthly  schedule  identifier  (ID27).  Unique  value  assigned 

by  the  program  to  distinguish  this  set  of  DS27  data.  User  may 
examine  or  change  or  delete  the  DS27  data  (Menu  Selection 
Sequence  7.4)  by  referring  to  this  number  or  may  indicate  the 
DS27  data  of  interest  by  providing  the  user/position 
identifier  (ID13/ID14)  and  the  year  and  the  month  for  the 
schedule.  The  1027  is  used  in  other  data  sets  to  indicate 
with  one  value  the  following  information:  The  user/position 
of  the  person  scheduled  to  perform  a  task  and  the  year  and 
month  in  which  the  task  is  scheduled.  To  provide  the  complete 
information  on  when  a  task  is  scheduled  to  start  or  end  it  is 
necessary  to  provide  the  ID27  plus  the  date,  hour  and  quarter 
of  an  hour.  This  complete  set  of  information  is  referred  to 
as  a  time  slot. 

2.  OHMIS  service  area  identifier  (ID1Q)  for  which  this  is  a 
monthly  schedule. 

3.  Year  for  which  this  is  a  monthly  schedule. 

4.  Month  for  which  this  is  a  monthly  schedule. 

5.  The  employee  identifier  (ID4)  for  the  person  for  whom  this 
is  a  monthly  schedule. 

6 .  OHMIS  user  identifier  or  position  identifier  (ID13/ID14)  for 
the  person  for  whom  this  is  a  monthly  schedule.  From  the 
current  user/position  identity  and  address  data  (DS9)  for  the 
above  employee  identifier  (ID4). 

7.  Date  (number  from  1  to  31)  of  the  month. 

The  following  3  sets  of  data  elements  for  each  of  the  dates 
of  the  month: 

7.1)  The  day  of  the  week  for  this  date  (Monday  through 
Sunday) . 

7.2)  Whether  any  part  of  this  day  is  available  for 
schedul ing. 

The  availability  data  on  the  regular  weekly  schedule 
availability  data  set  (DS26)  for  the  employee  for  which 
this  set  of  DS27  data  is  a  monthly  schedule  and  the  day 
of  the  week  given  above  is  used  to  identify  those  quarter 
of  an  hour  periods  (time  slots)  that  are  available  for 
scheduling.  Answers:  Yes/No.  If  none  of  the  time  slots 
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are  available  for  scheduling  on  this  day,  the  answer 
is  'No';  otherwise,  the  answer  is  'Yes'.  Also  the 
user  may  change  the  hours  available  for  scheduling 
as  a  part  of  changing  the  DS27  data  (Menu  Selection 
Sequence  7.3.2)  or  the  0S26  data  (Menu  Selection 
Sequence  7.2.3). 

7.3)  Each  day  of  the  month  has  96  time  slots  signifying 
the  hour  and  quarter  of  an  hour  in  the  day. 

Each  of  the  96  time  slots  have  the  following  data  elements: 

a)  A  time  slot  number  (1-96). 

b)  Whether  the  time  slot  is  available  for  scheduling. 
Answers:  Yes/No 

For  each  time  slot  identified  above  as  available  for 
scheduling: 

c)  The  preferred  time  use  code  (CT11)  for  the  time 
slot.  From  the  DS26  data  or  changed  by  the  user 
using  Menu  Selection  Sequence  7.3.2  or  7.2.3. 

d)  The  task  identifier  (ID23)  for  the  task  that  has 
been  scheduled  for  this  time  slot,  if  any  has  been 
scheduled  to  date. 

For  each  time  slot  identified  above  as  being  one  for  which  a 
task  has  been  scheduled: 

e)  Time  use  code  CT11)  for  the  task  with  the  ID23 
from  above.  This  may  not  be  the  same  as  the 
preferred  time  use  code  for  the  time  slot  given 
above  if  it  was  not  possible  to  schedule  this  time 
slot  according  to  the  user's  preferred  time  use  for 
the  time  slot.  (This  is  called  the  actual  time 
use  for  the  time  slot  in  some  Functions.) 

f)  Whether  the  scheduling  of  the  task  is  the  one 
specified  by  the  user.  Answer:  Yes/No.  The  OHMIS 
scheduling  program  (Function  F4A)  will 

1  automatical ly ‘  schedule  each  task.  However,  the 
user  may  change  the  scheduling  of  a  task  by  changing 
this  information  on  the  DS24  data  for  the  task  (Menu 
Selection  Sequence  7.4.1),  if  desired.  Such 
schedules  for  a  task  that  are  determined  by  the  user 
are  given  higher  priority  and  are  rescheduled; 
therefore,  the  fact  that  the  schedule  is  one 
specified  by  the  user  is  noted  here.  From  the  DS24 
data  for  the  task. 
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g)  Whether  there  are  any  restrictions  on  the  time 

that  this  task  has  been  scheduled.  Answers:  Yes/No 
and,  if  'Yes',  whether  the  restrictions  are 
standard  restrictions,  special  restrictions,  or 
both.  From  the  DS24  data.  This  information 
indicates  whether  the  DS24  data  needs  to  be  checked 
for  these  restrictions,  if  it  should  become 
necessary  to  reschedule  the  task. 

h)  The  total  standard  number  of  time  slots  required 
to  schedule  this  task.  From  the  DS24  data. 

i)  The  total  number  of  user  specified  time  slots  that 
are  required  to  complete  this  task.  From  the  DS24 
data.  The  amount  of  user  specified  time  slots  to 
complete  the  task  would  only  be  different  than  the 
total  standard  amount  of  time  to  complete  the 

task,  if  the  user  had  changed  this  value  on  the  DS24 
data.  This  would  be  done,  if  the  user  felt  that 
more  time  was  needed  for  this  particular  execution 
of  the  task  than  would  regularly  be  scheduled  for  a 
task  of  this  type.  The  user  specified  required  time 
slots  to  complete  a  task  would  also  be  different 
from  the  standard  required  time  slots,  if  the  user 
had  previously  started  completing  the  task  and  had 
not  completed  in  the  scheduled  time  period  and  had, 
therefore,  changed  the  amount  of  time  required  to 
scnedule  this  task  to  the  amount  of  time  left 
needed  to  complete  this  task.  The  standard  required 
time  slots  and  user  specified  time  slots  for 
completing  a  task  are  the  same  if  the  user  has  not 
specified  any  user  specified  required  time  slots. 

j)  The  actual  number  of  time  slots  required  to 
schedule  the  task  in  the  way  that  is  scheduled  on 
this  DS27  data.  One  time  slot  is  added  to  the  time 
slots  required  to  schedule  a  task  for  each 
interruption  in  the  scheduling  of  the  task. 

k)  Due  date  for  this  task  identifier  (ID23).  This 
information  comes  from  the  specific  task  scheduling 
data  (DS24)  for  the  above  task.  This  information  is 
used  to  determine  by  what  date  the  task  being 
scheduled  has  to  be  completed  in  order  to  meet  the 
due  date.  The  scheduling  program  (Function  F4A) 
attempts  to  arrange  the  scheduling  for  all  tasks  so 
that  they  are  all  completed  before  their  due  date. 

There  may  not  be  any  due  date  for  a  task.  Only 
tasks  triggered  by  requirements  implementation  data 
(OSb)  that  was  generated  from  requirements  suspense 
data  (DS4)  or  tasks  that  have  a  specified  length  of 
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time  for  completing  them  given  in  the  task  type 
description  data  (DS23)  are  dated.  The  DS24  data  on 
each  task  indicates  whether  it  is  a  dated  task  by 
giving  the  due  date  for  the  task. 

l)  For  tasks  triggered  by  DS5  data  generated  from 
suspense  requirements  data  (DS4  data),  whether  the 
DS4  data  was  for  a  requirement  type  of  suspense 
for  a  Reminder  Notice  type  of  suspense.  Answer: 
Yes/No.  Reminder  Notice  type  of  DS4  data  trigger 
actions  that  are  not  based  on  any  requirement  or 
recommendation,  i.e.,  not  linked  to  requirement 
(recommendation)  description  data  (DS1).  Although 
these  tasks  do  have  due  dates,  the  meeting  of  these 
dates  is  not  as  critical  as  it  is  in  a  required 
dated  action  and  therefore,  in  scheduling,  other 
tasks  are  not  bumped  to  a  later  date  to  meet  th  due 
date  for  Reminder  Notice  (nonrequirement)  type 
suspenses.  The  OHMIS  scheduling  program  gives 
higher  priority  to  required  tasks  that  are  dated  and 
will,  for  example,  "bump"  nondated  tasks  to  a  later 
date,  if  necessary  to  enable  scheduling  of  required 
dated  tasks  before  the  due  date.  The  DS24  data  for 
the  above  task  identifier  (ID23)  indicates  whether 
the  task  is  generated  from  Reminder  Notice  types 
requirements  suspense  data  (DS4). 

m)  If  the  task  is  not  a  Reminder  Notice  type  of  task, 
whether  the  task  is  based  on  a  mandatory 
requirement  or  a  recommended  requirement.  Again, 
this  is  used  to  determine  priority  in  scheduling. 
From  the  DS24  data  for  the  task. 

n)  Whether  a  task  is  an  'employee  transport1  type  of 
task,  i.e.,  one  that  requires  taking  the  employee 
participating  in  the  task  away  from  his/her  work 
site.  Employee  transport  tasks  that  are  already 
scheduled  have  the  highest  priority  in  scheduling. 
They  will  not  be  bumped  for  any  other  task.  Also, 
this  information  is  used  to  attempt  to  schedule  all 
employee  transport  type  tasks  for  a  given  employee 
(including  all  tasks  scheduled  for  up  to  three 
months  in  advance)  at  the  same  time. 

o)  Whether  this  task  is  one  for  which  a  Scheduling 
Notice  (015)  is  required.  From  the  DS23  data. 

Tasks  that  require  Scheduling  Notices  are  given 
higher  priority  (i.e.,  are  not  rescheduled  as 
readily)  than  those  which  do  not  require  these 
notices  because  rescheduling  of  the  tasks  means 
resending  a  Scheduling  Notice.  Therefore,  this 
characteristic  of  the  task  is  noted  here. 
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p)  The  cumulative  number  of  time  slots  scheduled  for 
this  task  as  of  this  time  slot.  For  example,  a 
task  that  takes  five  time  slots  to  schedule  would 
have  the  first  time  slot  scheduled  with  the 
cumulative  number  of  *1'  in  this  field,  the  second 
time  slot  scheduled  would  have  a  '2'  in  this  field, 
etc. 

q)  The  cumulative  number  of  interruptions  in  the 
scheduling  of  this  task  as  of  this  time  slot. 
Interruptions  are  breaks  in  the  continuous 
scheduling  of  a  task,  e.g.,  if  a  time  slot  for  the 
end  of  the  work  day  arrives  before  the  last  time 
slot  used  to  schedule  this  task,  this  would  be  an 
interruption  in  the  scheduling  of  the  task.  One 
time  slot  is  added  to  the  number  of  time  slots 
required  to  complete  the  task  for  each  interruption 
in  the  task. 

r)  Whether  the  above  task  is  continued  to  other  time 
slots,  i.e.,  the  time  required  for  scheduling  the 
task  is  greater  than  this  one  quarter  of  an  hour 
time  slot.  Answers:  Yes/No.  This  field  is 
especially  important  in  processing  scheduling  data 
because  it  indicates  whether  there  are  interruptions 
in  the  scheduling  of  a  task,  i.e.,  it  identifies 
tasks  that  have  breaks  or  other  tasks  scheduled 
between  the  start  and  stop  time  for  the  task. 

s)  Time  slot  information  for  the  next  time  slot  in 
which  this  task  is  scheduled.  Time  slot 
information  is  a  monthly  schedule  identifier  (ID27), 
a  date  (1-31)  and  a  time  slot  number  (1-96, 
indicating  the  quarter  of  an  hour  of  a  day).  This 
information  tells  the  reader  of  the  monthly  schedule 
which  time  slot  is  the  next  time  slot  scheduled  for 
the  completion  of  this  task  after  the  time  slot 
being  described  in  this  set  of  fields.  This  allows 
the  program  to  know  to  which  time  slot  to  go  in 
order  to  identify  and  locate  all  time  slots 
scheduled  for  a  task. 


DATA  SET  28 


Contact  and  Location  Data 


This  data  describes  information  about  how  to  contact  or  locate  a  person. 
It  also  identifies  and  describes  how  to  locate  the  person  to  contact 
regarding  occupational  health  program  matters  with  reference  to 
inanimate  things;  for  example,  the  person  to  contact  for  information 
about  a  facility  or  a  job  class  is  identified  on  the  DS28  data.  The 
DS28  data  is  distinguished  from  the  current  user/position  identity  and 
address  data  (DS9)  in  that  the  DS9  data  only  provides  contact  and 
location  information  for  users  of  OHMIS  and  for  positions  routinely 
contacted  in  the  use  of  OHMIS,  e.g.,  the  mailing  address  of  the 
personnel  office,  while  the  DS28  data  provides  contact  and  location  data 
for  all  other  persons  and  for  some  things. 

The  primary  purpose  of  the  0S28  data  is  to  identify  the  person(s)  that 
should  be  notified  about  an  occupational  health  program  action,  i.e., 
the  persons  sent  a  Scheduling  Notice  (Output  015)  for  a  task  triggered 
by  OHMIS.  The  0S28  data  also  serves  to  identify  any  standard  (i.e., 
routine)  restrictions  on  the  scheduling  of  tasks  for  the  person  or  thing 
covered  by  the  set  of  DS28  data.  It  is  expected,  however,  that  the  DS28 
data  may  be  used  for  numerous  routine  occupational  health  program 
functions  that  require  information  on  how  to  contact  individuals,  e.g., 
sending  training  materials  to  employees. 

The  DS28  data  is  entered  by  the  user  using  Menu  Selection  Sequence 
8.2.1.  This  data  can  be  changed  or  deleted  by  the  user.  Only  current 
DS28  data  is  maintained.  It  is  expected  that  each  OHMIS  service  area 
will  have  their  own  series  of  sets  of  DS28  data.  Because  it  is  possible 
to  have  one  set  of  DS28  data  for  each  employee  (and  possibly  for  each 
facility,  job  class,  organizational  unit  and  other  things  for  which 
contact  and  location  information  are  needed)  in  an  OHMIS  service  area, 
it  is  expected  that  an  automated  method  for  generating  the  0S28  data 
(using  an  external  data  source  such  as  a  personnel  information  system) 
will  be  developed. 

1.  Contact  identifier  (ID26).  Unique  value  assigned  by  the 
program  to  distinguish  this  set  of  DS28  data. 

2.  OHMIS  service  area  identifier  (ID10)  for  the  service  for 
which  this  set  of  0S28  data  provides  contact  and  location 
information. 

3.  Identifier  of  the  person  or  thing  about  which  this  set  of 
DS28  data  provides  contact  and  location  information.  This  can 
be  an  individual  (ID4),  a  job  class  (107),  a  facility  (ID8), 
an  installation  (1011),  an  organizational  unit  (1012)  or  other 
similar  types  of  identifiers  of  persons  or  things  or  groups  of 
persons  or  things  about  which  it  is  useful  to  maintain  contact 
and  location  data. 
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4.  Employee  identifier  (ID4)  of  the  person  to  contact  for 
information  about  the  above  identifier.  If  the  identifier 
given  above  was  a  person  (i.e.,  an  employee  identifier  (ID4)), 
this  ID4  ma^  be  the  same  as  that  employee  identifier,  but  it 
is  not  necessarily  the  same.  For  example,  the  contact  person 
for  an  employee  with  regard  to  the  occupational  health  program 
may  be  the  employee's  supervisor,  rather  than  the  employee 
himself.  As  the  DS28  data  is  used  primarily  to  determine  to 
whom  to  send  Scheduling  Notices  (015)  for  QHMIS  tasks,  the 
appropriate  person  for  sending  these  Notices  to  should  be  used 
here. 

If  the  above  identifier  was  not  for  a  person,  this  employee 
identifier  (ID4)  would  be  the  person  to  contact  about 
occupational  health  issues  for  the  above  identifier.  For 
example,  a  facility  may  have  a  person  to  contact  in  order  to 
notify  the  person  responsible  for  the  facility  of  an 
industrial  hygiene  survey  (e.g.,  to  gain  access)  or  to  inform 
the  person  responsible  for  the  facility  of  a  needed  corrective 
action.  Similarly,  there  may  be  a  need  to  identify  a  person 
to  contact  for  information  about  a  given  job  class  (e.g.,  to 
obtain  updated  information  about  hazards  about  the  job  class). 

5.  Work  address  information  for  the  above  person.  This 
information  can  include  the  title  of  the  person,  mailing 
address,  phone,  etc.  The  mailing  address  can  be  the 
abbreviated  form  of  mailing  information  used  internally  in  the 
Department  of  the  Army  (i.e.,  office  identifier  and  mail 
slot).  Depending  on  the  nature  of  the  particular  occupational 
health  programs  implemented,  it  may  be  found  desirable  to 
include  a  home  address  for  employees  as  well  as  a  work 
address . 

6.  Whether  there  are  any  standard  restrictions  on  the 
scheduling  of  tasks  for  the  above  identifier.  The  OHMIS 
scheduling  program  (Function  F4)  assumes  a  24-hour  day,  7-day 
a  week  work  schedule  in  order  to  allow  for  those  installations 
in  which  multiple  shifts  of  occupational  health  services  are 
provided.  In  order  not  to  schedule  a  person  or  thing  to 
participate  in  a  task  ojring  a  time  period  in  which  the  person 
or  thing  is  regularly  known  not  to  be  available  (i.e.,  known 
to  not  be  on  a  work  shift),  the  program  identifies  those  time 
slots  that  the  person  or  thing  is  not  available  to  participate 
in  tasks  on  a  set  of  weekly  schedule  identifier  data  (DS26). 
For  example,  an  employee  may  work  the  swing  shift  and  only  be 
available  for  medical  examinations  during  the  swing  shift 
hours;  the  remaining  hours  will  be  restricted  hours. 

Similarly,  there  may  be  certain  facilities  for  which  it  is  not 
possible  to  enter  or  conduct  industrial  hygiene  surveys  at  all 
times;  the  times  where  it  is  not  acceptable  to  do  so  would  be 
identified  as  restricted  times.  Only  standard  restrictions 
are  referred  to  here,  i.e.,  restrictions  that  routinely  apply. 
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If  there  is  a  period  of  time  that  the  person  or  thing  is 
normally  available  for  scheduling,  but  will  not  be  available 
for  scheduling  temporarily  (i.e.,  while  the  person  is  on  a 
leave  of  absence)  this  would  be  shown  on  the  specific  task 
scheduling  data  (0S24)  for  the  task(s)  in  which  the  person  or 
thing  is  currently  scheduled  to  participate. 

If  the  answer  to  the  above  question  was  'Yes',  the  weekly 
schedule  identifier  (ID28)  for  the  regular  weekly  schedule 
availability  data  (DS26)  containing  information  about  the 
restricted  times.  It  is  expected  that  in  many  cases  the  exact 
same  standard  restrictions  on  scheduling  will  apply  to  large 
numbers  of  persons  and/or  things.  Thus,  for  example,  all 
employees  working  on  a  given  shift  would  have  the  same 
restrictions  on  times  for  scheduling.  Also,  the  working  hours 
may  be  known  for  an  entire  OHMIS  service  area  or  installation. 
For  this  reasons,  the  restricted  times  are  not  entered  for 
each  person  or  thing,  i.e.,  it  is  not  entered  on  each  set  of 
DS28  data.  Instead,  the  DS28  data  for  an  individual  or 
specific  thing  refers  to  one  set  of  regular  weekly  schedule 
availability  data  (DS26)  that  contains  the  restrictions 
information  applying  to  that  individual  or  thing.  Thus, 
multiple  individuals  or  things  may  refer  to  the  same  set  of 
0S26  data  for  information  about  restricted  times. 


6.7  OUTPUTS 

The  following  are  the  description  of  the  Outputs  that  are  used  in  the 
Functional  Data  Flows  describing  the  core  OHMIS  data  processing 
functions . 
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TITLES  OF  OUTPUTS 


Output  Number 
01 
02 
03 

04 

05 

06 

07 

08 

09 

010 

Oil 

012 

013 

014 

015 

016 

017 


Output  Title 

Requirements  Check  Notice 

Outstanding  Requirements  Checks  Needed  List 

Requirements  Notification  and  Certification 
Record 

Outstanding  Requirements  List  (see  DL3) 

Reminder  Notice  List  (see  DL9) 

Vacant  Job  Class  List  (see  DL1) 

Potential  New  Hire  List  (see  D12) 

New  Hire  List  (see  DL4) 

Allowable  Limits  Check  Notice 

Outstanding  Allowable  Limits  Checks  Needed 
List 

Allowable  Limits  Evaluation  Summary 

OHMIS  'Blank'  Form  (see  Form  Types)  [Generic 
Description  of  All  OHMIS  'Blank'  Forms] 

Outstanding  Data  Requests  List  (see  DL27  and 
DL28) 

Dai ly  Schedule 
Scheduling  Notice 
Scheduled  Task  Description 
List  of  Unscheduled  Tasks 
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OUTPUT  01:  Description 


Requirements  Check  Notice 


The  Requirements  Check  Notice  is  used  to  tell  the  user  (OHMIS  Data 
Processing  Staff)  that  a  particular  triggering  step  has  been  executed 
and  that  information  triggered  requirements  (DS3  data)  potential 1y 
associated  with  this  triggering  step  have  been  identified,  but 
insufficient  information  is  available  to  be  certain  and  that,  therefore, 
a  requirements  check  (Menu  Selection  1.2.3;  Function  F2A)  should  be 
made.  The  notice  provides  a  description  of  the  potentially  applicable 
requirements  for  which  the  user  will  be  checking  appl icabi 1 i ty  as  a  part 
of  the  requirements  check  requested  by  this  Requirements  Check  Notice. 
Potentially  applicable  requirements  are  those  requirements  which  have 
passed  all  of  the  applicability  criteria  for  those  applicability 
variables  for  which  the  values  were  available  in  the  OHMIS  data  base  at 
the  time  that  the  triggering  step  initiating  this  requirements  check 
request  was  executed.  The  01  output  also  provides  the  reason  why  this 
requirements  check  was  triggered  and  the  values  for  the  requirement 
implementation  units,  i.e.,  a  unit  such  as  an  employee  or  a  facility  to 
which  the  potentially  applicable  requirements  may  apply,  for  which  this 
requirements  check  is  to  be  executed.  The  notice  also  tells  the  user 
the  types  of  data  elements  that  the  user  should  have  available  when 
executing  the  requirements  check  in  order  to  be  able  to  provide  the  data 
needed  to  determine  if  the  requirements  are  applicable,  i.e.,  the 
applicability  characteristics  data  element  type  for  which  the  OHMIS 
requirements  check  program  was  not  able  to  obtain  from  the  current  OHMIS 
data  base  at  the  time  that  the  triggering  step  was  initiated.  The  user 
must  be  prepared  to  enter  the  values  for  these  data  elements  (i.e.,  the 
values  for  the  requirements  applicability  characteristics  (DS8)) ,  when 
making  the  requirements  check,  so  that  the  program  can  identify  the 
applicable  requirements.  The  Requirements  Check  Notice  identifies  those 
requirement  applicability  characteristics  data  elements  for  which  the 
current  OHMIS  data  base  does  not  have  values,  i.e.,  those  for  which  the 
computer  program  could  not  "automatically"  obtain  the  values  at  the  time 
of  the  requirements  check  request  data  (DS2)  was  generated. 

Generation  of  Output:  Most  of  the  01  data  is  generated  from  the 
requirements  check  request  data  (DS2).  The  output  is  generated  by  the 
user  through  Menu  Selection  Sequence  1.2.1.  Request  for  this  type  of 
output  can  be  for  several  subsets  of  requirements  check  request  data 
(DS2),  including: 

o  All  Requirements  Check  Notices  (01)  for  a  given  OHMIS  service 
area  identifier  (ID10);  the  ID10  is  on  the  Requirements  Check 
Request  Data  (DS2).  As  DS2  data  is  only  kept  for  outstanding 
requirements  check  requests  (i.e.,  those  checks  that  have  not 
been  executed,  this  selection  criteria  of  the  01  output  would 
yield  all  uncompleted  requirements  checks  applicable  to  a 
given  OHMIS  service  area. 
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o  A  specific  requirements  check  notice  as  specified  by  the  user 
using  the  requirements  check  request  identifier  (ID1)  which  is 
obtained  by  the  program  from  the  requirements  check  request 
data  (DS2)  and  provided  to  the  user  on  the  Outstanding 
Requirements  Checks  Needed  Lists  (02). 

o  The  Requirements  Check  Notice  (01)  for  requirement  check 
request  data  triggered  between  a  specified  range  of  dates. 

The  date  on  which  the  requirements  check  request  was  triggered 
is  obtained  by  the  program  for  the  requirements  check  request 
data  (DS2). 

o  The  Notice  for  all  requirements  checks  triggered  by  a  given 
triggering  step.  The  triggering  step  is  given  on  the 
requirements  check  request  data  (DS2). 

Data  for  the  01  output  shown  on  the  following  mock  up  is  obtained  from 
the  requirements  check  request  data  (DS2)  for  the  particular 
requirements  check  request  identifier  (IDl)  shown  on  the  output,  unless 
otherwise  specified  in  the  mock  up. 
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OUTPUT  01:  hock  Up 
TITLE:  Requirements  Check  Notice 


1.  Instructions  to  the  user  on  how  to  use  this  output,  i.e.,  that 
the  user  must  execute  a  requirements  check  in  which  the  values  for 
the  missing  applicability  characteristic  types  (variables)  shown 
below  will  be  supplied  by  the  user  and  the  program  will  then  use 
these  values  to  determine  if  there  are  any  applicable  requirements. 
Includes  how  to  execute  a  requirements  check  (Menu  Selection 
Sequence  1.2.3).  This  data  is  the  same  for  all  Requirements  Check 
Notices . 

2 .  Requirements  check  request  identifier  (IDl). 

3.  Date  this  requirements  check  request  was  triggered. 

4.  OHMIS  service  area  identifier  (ID1Q)  from  which  this  requirements 
check  request  originated. 

5.  Triggering  step  identifier  (ID2)  for  the  triggering  step  in  which 
this  requirements  check  request  was  generated. 

6.  Description  of  the  triggering  step.  Obtained  from  the  triggering 
step  identifier  (ID2)  data.  I  hi s  information  informs  the  user  of 
the  occasion  (i.e.,  the  data  processing  function)  that  triggered  a 
request  for  a  requirements  check,  e.g.,  that  the  user  added  a  job 
class  to  the  vacant  job  class  list  (DL1). 

7.  Data  element  types  and  values  for  the  requirement  implementation 
units  entered  during  the  execution  of  the  above  referenced 
triggering  step.  This  data  provides  further  information  on  the 
particular  data  processing  function  that  triggered  this 
requirements  check  request,  e.g.,  the  specific  job  class  that  was 
added  to  the  vacant  job  class  list. 

8.  The  requirement  identifier  (ID6)  and  brief  requirement 
description  for  each  potentially  applicable  requirement  included 
in  this  requirements  check  request.  The  requirement  identifier  is 
obtained  from  the  values  data  for  requirements  applicability 
characteristics  (DS3)  for  e-iCh  potentially  applicable  requirement, 
i.e.,  for  eacn  set  of  DSJ  data  for  the  above  referenced 
requirements  check  request  identifier  (IDl).  This  information 
tells  the  user  what  potentially  applicable  requirements  are  to  be 
checked  for  in  the  requirements  check  requested  by  this  Notice, 
thus,  informing  the  user  of  the  significance  of  this  requirements 
check . 

9 .  The  data  element  types  on  the  list  of  requirements  applicability 
characteristics  for  which  values  are  missing  (Dip)  for  the  above 
referenced  requirements  check  request  identifier  (IDl).  This  list 
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tells  the  user  what  types  of  data  elements  he/she  should  have 
available  in  order  to  fill  in  the  missing  values  as  a  part  of 
executing  the  requirements  check.  Once  these  missing  values  are 
supplied  by  the  user  during  a  requirements  check,  the  program 
(Function  F2A)  will  be  able  to  check  whether  any  of  the  potentially 
applicable  requirements  are  in  fact  applicable  by  matching  these 
values  to  the  specified  applicability  characteristic  values  for 
each  potentially  applicable  requirement. 
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OUTPUT  02:  Mock  Up 


TITLE:  Outstanding  Requirements  Checks  Needed  List 


Instructions  to  the  user  on  how  to  use  this  output.  Includes 
telling  the  user  to  use  this  summary  to  obtain  the  complete 
information  on  the  requirements  check  request  by  generating  the 
Requirements  Check  Notice  (01)  for  the  requirements  check  request 
identifier  (IDl)  given  on  this  list. 

The  triggering  step  identifier  (ID2)  for  which  this  constitutes  a 
list  of  requirements  checks  needed  as  specified  by  the  user.  The 
output  would  read  ‘all1,  if  not  specified  by  the  user. 

Date  this  output  was  generated. 

OHMIS  service  area  identifier  (ID10)  for  which  this  is  a  list  of 
requirements  checks  needed.  This  identifier  is  specified  by  the 
user;  or,  (for  automatically  generated  02  output),  determined  by 
the  program  based  on  the  OHMIS  user  identifier  (ID13)  and  at  the 
beginning  of  the  log  on  program  sequence  in  which  this  output  was 
generated . 

For  and  to  dates  for  the  time  period  covered  by  the  requirements 
check  requests  listed,  i.e.,  the  time  period  between  which  a 
requirement  check  request  needs  to  have  been  triggered  for  it  to  be 
listed  on  this  output.  Specified  by  the  user  or  the  word  'all'. 

Four  columns  of  data  listing  the  following  selected  data  elements 
for  all  specified  requirements  check  request  data  sets  (DS2): 

1)  Requirements  check  request  identifier  (IDl). 

2)  Date  on  which  the  requirements  check  request  was  triggered. 

3)  Triggering  step  identifier  (ID2)  for  the  triggering  step  in 
which  this  requirements  check  request  was  generated. 

4)  Description  of  the  triggering  step.  Obtained  from  the 
triggering  step  identifier  (ID2)  listed  above. 
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Outstanding  Requirements  Checks  Needed  Lists 


This  output  lists  selected  data  elements  from  the  -'equirements  check 
request  data  (DS2)  for  all  requirements  check  requests  made  for  a  given 
OHMIS  service  area.  The  purpose  for  the  output  is  to  provide  the  user 
with  a  summary  list  of  all  requirements  check  requests  that  have  been 
triggered  (by  executing  triggering  steps),  but  which  have  not  yet  been 
conducted.  The  list  is  generated  daily  and  thus  acts  as  a  check  list 
telling  the  user  of  requirements  checks  that  need  to  be  made  for  that 
day.  Further  information  on  the  requirements  check  requests  can  be 
obtained  from  the  Requirements  Check  Request  Notice  (01)  using  the 
requirements  check  request  identifier  (ID1)  which  is  given  on  02. 

Because  the  requirements  check  request  data  (DS2)  is  deleted  when  the 
requirements  check  (Menu  Selection  Sequence  1.2.3;  Function  F2A)  is 
executed,  there  is  data  in  the  OHMIS  data  base  only  on  uncompleted 
requirements  checks. 

Generation  of  Output:  Most  of  the  OHMIS  data  is  obtained  from  the 
requirements  check  request  data  (DS2).  The  output  is  generated  in  two 
ways : 

1)  ‘Automatically1  (see  Function  F1A):  The  complete  02  list 
(all  requirements  check  request  data  for  an  OHMIS  service  area 
identifier  (ID10))  is  generated  once  each  day  that  the  OHMIS 
Data  Processing  Staff  person  for  the  service  area  logs  onto 
the  OHMIS  system.  The  log  on  program  keeps  track  of  the  last 
date  on  which  the  02  list  was  generated  and  compares  it  with 
the  current  date  each  time  a  user  with  an  OHMIS  user 
identifier  (ID13)  that  is  for  a  data  processing  staff  type  of 
user  (CT1)  enters  the  system  for  a  given  OHMIS  service  area. 
The  list  is  generated  for  the  OHMJS  service  area  identifier 
(ID10)  associated  with  the  OHMIS  user  logging  onto  the  system, 
using  the  OHMIS  user  identifier  by  service  area  list  (DL6). 

2)  Upon  the  request  of  the  user,  using  Menu  Selection  Sequence 
1.2.2.  The  user  may  specify  that  this  output  includes: 

j  All  requirements  check  requests  for  a  service  area 
( ID10) . 

o  Requirements  check  request  generated  between  a  specified 
range  of  dates. 


o 


Requirements  check  request  for  a  given  triggering  step 
(ID2). 


OUTPUT  03:  Description 


Requirements  Notification  and  Certification  Record 


This  output  notifies  the  user  of  a  particular  requirement  (recommenda¬ 
tion)  that  needs  to  be  implemented  and  provides  a  blank  form  for 
completing  (manually)  the  disposition  data  on  the  requirement,  i.e., 
data  on  who  executed  the  requirement  and  what  type  of  execution  of  the 
requirement  took  place.  This  output  may  thus  become  a  hard  copy 
record  containing  disposition  data.  If,  for  example,  it  is  desired  to 
keep  a  permanent  hard  copy  record  of  the  signatures  of  the  persons  who 
executed  the  requirement  and  approved  the  disposition  of  the  require¬ 
ment,  this  output  would  be  the  document  that  was  kept.  The  requirement 
description  data  (DS1)  for  the  output  specifies  whether  such  a  hard  copy 
record  of  the  03  output  is  to  be  maintained. 

This  output  provides  a  description  of  the  requirement  and  the  Menu 
Selection  Sequence  steps,  if  any,  involved  in  conducting  the  data 
processing  steps  needed  to  execute  the  requirement.  It  also  indicates 
any  additional  checks  that  should  be  executed  to  determine  if  the 
requirement  is  applicable  and  the  Menu  Selection  Sequence  for  conducting 
the  data  processing  steps,  if  any,  involved  in  making  these  additional 
checks.  The  data  entry  portion  on  this  output  provides  a  means  for  the 
user  to  manually  complete  the  disposition  on  the  requirement.  The  value 
for  the  disposition  data  entered  on  this  output  are  entered  into  the 
OhMIS  data  base  as  a  part  of  the  requirement  implementation  data  (DS5), 
using  Menu  Selection  Sequence  1.5.3  (Function  F2B) . 

Generation  of  Output:  The  data  from  the  03  output  comes  primarily 
from  the  DS5  data.  The  requirement  description  data  (DSl)  corresponding 
to  the  requirement  identifier  (ID6)  given  on  the  DS5  data  is  another 
major  source  of  data  for  this  output  as  are  the  requirements  appli¬ 
cability  data  (DS3,  DS4  or  DS17)  corresponding  to  the  requirements 
application  identifier  (ID5)  given  on  the  DS5  data. 

The  output  is  generated  by  the  user  through  Menu  Selection  Sequence 
1.5.1.  Requests  for  this  type  of  output  can  be  for  several  subsets  of 
the  DS5  data,  including: 

o  All  Requirement  Notification  and  Certification  Records  (03) 

for  a  given  OHMIS  service  area  identifier  ( ID 10 ) .  The  I D 10  is 
on  the  0S5  data.  This  would  only  include  03  records  for 
requirements  that  have  not  yet  been  executed  as  identified  on 
the  Outstanding  Requirement  ist  (0L3). 

o  A  specific  03  as  specified  by  the  user  using  the  requirement 
implementation  identifier  (ID9)  which  is  obtained  from  the  DS5 
data  and  provided  to  the  user  on  the  Outstanding  Requirements 
List  (04).  All  03s  for  requirements  for  which  the  requirement 
implementation  data  (DS5)  was  generated  (i.e.,  the  requires  a : 
was  triggered),  between  a  specified  range  of  dates.  The  ata 
is  obtained  from  the  DS5  data. 


All  03s  for  requirements  of  a  given  OHMIS  requirement  type 
code  (CT3).  This  code  is  from  the  DS1  data. 

All  03s  for  requirements  of  a  given  requirement  identifier 
(ID6).  from  the  DS5  data. 

All  03s  that  are  supposed  to  be  executed  by  a  given  OHMIS  user 
type  (CT1)  or  position  type  (CT2).  From  the  0S1  data. 

All  03s  that  are  supposed  to  be  executed  by  a  given  OHMIS  user 
identifier  (ID13),  position  identifier  (ID14)  or  employee 
identifier  (104).  From  the  DS5  data. 

Same  as  above  to  selection  criteria',  except  for  the  person  who 
is  supposed  to  supervise  the  execution  of  the  requirement 
(i.e.,  receive  notices  about  the  requirement). 

Same  as  the  above  to  selection  criteria  except  for  the  person 
who  is  supposed  to  approve  the  disposition  of  the  requirement. 
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TITLE:  Requirement  Notification  and  Certification  Record 


Instructions  for  how  to  use  this  output.  Includes  how  to  get 
more  information  about  the  requirement  by  examining  the 
requirements  description  data  (DS1)  through  Menu  Selection  Sequence 
1.1.2  and  how  to  get  more  information  about  the  applicability  of 
the  requirement  by  examining  the  appropriate  DS3,  DS4  or  DS17  data. 

Requirement  implementation  identifier  (ID9)  for  the  requirement 
implementation  data  (0S5)  for  which  this  Record  was  generated. 

Date  that  the  requirement  was  triggered,  i.e.,  the  date  that  the 
requirement  implementation  data  (DS5)  was  generated.  From  the  DS5 
data. 

Document  identifier  type  code  (CT6)  assigned  to  all  Requirement 
Notification  and  Certification  Records  (03)  and  the  type  of  OHMIS 
document. 

Document  identifier  (ID3)  assigned  to  all  Requirement 
Notification  and  Certification  Records  (03s)  generated  for  the 
above  requirement  implementation  identifier  (ID9).  This  is  a 
unique  value  assigned  by  the  program  to  distinguish  this  record 
from  other  03  records.  This  value  is  assigned  at  the  time  that  the 
DS5  data  is  generated  from  the  list  of  available  document 
identifiers  (ID3),  rather  than  at  time  that  the  03  is  generated,  in 
order  to  have  the  same  document  identifier  on  all  generations  of  an 
03  output  for  a  given  set  of  requirement  implementation  data  (DS5), 
to  allow  for  the  fact  that  the  same  03  output  may  be  generated 
several  times. 

Length  of  time  that  the  completed  version  of  this  03  record  must 
be  maintained.  Tells  user  whether  or  not  the  hard  copy  of  this  03 
record  must  be  retained  in  order  to  document  the  requirement's 
execution  and  approval  signatures  and,  if  so,  for  how  long.  From 
the  DS1  data. 

OHMIS  service  area  identifier  ( I DIO )  to  which  this  requirement 
applies.  From  the  DS5  data. 

The  OHMIS  user  identifier  ( I Dl 3 )  or  position  identifier  (ID14) 
and  employee  identifier  (ID4)  for  the  person  who  is  supposed  to 
execute  this  requirement.  From  the  DS5  data. 

Same  as  above  except  for  the  person  who  is  supposed  to  supervise 
the  requirement,  i.e.,  the  person  who  is  to  be  notified  of  this 
requirement  in  order  to  manage  its  execution. 


10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

18. 


19. 

20. 


Same  as  above  except  for  the  person  who  is  supposed  to  approve  the 
disposition  of  the  requirement,  if  any  such  person  has  been 
specified. 

Whether  this  requirement  is  mandatory  (i.e.,  "fully  completed"  is 
the  only  acceptable  disposition)  or  only  recommended.  From  DS1 
data. 

Date  that  this  requirement  is  due  (for  date  triggered  requirement 
(DS4  data)  or  for  requirements  for  which  a  recommended  length  of 
time  for  completing  the  requirement  has  been  given  in  the  DS 1 
data).  From  DS5  data. 

Length  of  time  recommended  to  complete  the  requirement.  From  DS1 
data. 

What  types  of  dispositions  of  this  requirement  need  approval.  From 
DS1  data. 

OHMIS  requirement  identifier  (ID6)  for  this  requirement.  From 
DS5  data. 

OHMIS  requirement  type  code  (CT3)  and  description.  From  DS1 
data. 

Detailed  description  of  the  requirement.  From  DS1  data. 

Supplemental  description  of  the  requirement.  Form  the  DS3,  DS4 
or  DS17  data. 

Rationale  for  which  this  requirement  was  triggered.  From  the 
DS3,  DS4  or  DS 17  data.  For  all  allowable  limits  triggered 
requirements  (i.e.,  those  triggered  from  DS 1 7  data),  this  includes 
the  statement  from  the  allowable  limits  applicability  values  data 
(DS16)  corresponding  to  the  allowable  limits  application  identifier 
(ID20)  given  on  the  DS17  data  that  is  referenced  by  the  requirement 
application  identifier  (ID5)  that  is  given  on  the  above  identified 
set  of  DS5  data.  This  statement  explains  why  a  particular  set  of 
allowable  limits  was  used  in  the  allowable  limits  evaluation,  i.e., 
what  allowable  limit  applicability  characteristics  the  forms  units 
had  that  determined  which  particular  set  of  allowable  limits  was 
used. 

The  values  for  the  requirement  implementation  units  for  this 
implementation  of  the  requirement.  From  DS5  data. 

The  Menu  Selection  Sequence  for  the  data  processing  steps  (if  any) 
that  are  involved  in  the  execution  of  this  requirement.  From  DS1 
data. 
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21.  Any  additional  checks  that  should  be  made  manually  to  determine  if 
this  requirement  is  applicable  and  the  Menu  Selection  Sequence  for 
the  data  processing  steps  (if  any)  involved  in  making  these 
checks.  From  the  DS3,  DS4  or  DS17  data. 

22.  Identifier  of  the  organizational  level  at  which  this  requirement 
applies,  if  it  applies  at  a  type  of  organizational  level  (CT5) 
other  than  the  OHMIS  service  area  (1010).  From  the  DS3,  DS4  or 
DS17  data. 

23.  Description  of  the  applicability  of  the  requirement.  From  the  DS1 
data. 

24.  The  values  for  the  applicability  characteristics  for  this 
implementation  of  the  requirement.  For  information  triggered  (DS3) 
and  allowable  limits  triggered  (DS17)  requirements  only.  From  DS5 
data. 

25.  Completed  form  identifier  (ID18)  for  the  form  on  which  the  data 
triggering  this  requirement  was  entered.  For  allowable  limits 
triggered  (0S17)  requirements  only.  From  DS5  data. 

26.  The  values  for  the  forms  units  that  were  used  in  the  evaluation 

of  allowable  limits  that  triggered  this  requirement.  For  allowable 
limits  triggered  (DS17)  requirements  only.  The  DS17  data 
identifies  which  of  the  forms  unit  values  on  the  completed  forms 
data  (DS14 )  identified  by  the  above  ID18  are  the  forms  units  that 
were  used  in  the  evaluation  of  allowable  limits. 

27.  The  values  for  the  data  element  types  in  the  forms  subpart  that 
was  evaluated  for  allowable  limits  in  the  allowable  limits 
evaluation  that  triggered  this  requirement,  i.e.,  the  actual  data 
entered  onto  the  completed  forms  data  (DS14)  for  the  ID18  given 
above  that  triggered  the  allowable  limit  requirement.  For 
allowable  limit  requirements  applicable  to  forms  subparts  (not 
forms-as-a-whole)  only.  The  D517  data  identifies  which  form 
subpart  was  used  in  the  allowable  limits  evaluation  that  triggered 
this  requirement;  the  DS14  data  for  the  above  ID18  gives  the  forms 
specification  identifier  (ID16)  for  the  forms  specification  data 
(DS10)  that  indicates  where  the  forms  subpart  data  is  located;  the 
DS14  data  gives  the  values  for  this  forms  subpart. 

28.  Completed  forms  identifier  (ID18)  and  values  for  the  base  line 
entries  used  in  the  evaluation  of  the  allowable  limits  which 
triggered  this  requirement.  For  allowable  limits  triggered 
requirements  that  are  applicable  to  forms  subparts  (not 
forms-as-a-whole)  only.  From  the  DS5  data. 

Task  identifier  ( ID23)  for  the  task  that  was  triggered  to  meet 
this  requirement,  if  any.  From  the  DS5  data. 


29. 
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30.  Detailed  description  of  the  task  corresponding  to  the  above 
referenced  task  identifier  (ID23).  From  the  task  type  description 
data  (DS23)  and  from  the  specific  task  scheduling  data  (DS24),  if 
a  supplemental  description  is  provided  on  the  DS24  data. 

Disposition  Data 

Data  entry  spaces  for  completing  the  following  disposition  data.  (When 
this  data  is  entered  onto  the  OHMIS  data  base  it  is  stored  on  the 
requirement  implementation  data  (DS5);  once  this  data  is  entered  the 
requirement  implementation  identifier  data  (ID9)  is  removed  from  the 
Outstanding  Requirements  List  (DL3),  because  the  entry  of  this  data 
indicates  that  the  requirement  has  been  completed;  also,  any  tasks  that 
were  triggered  to  execute  this  requirement  (see  specific  task  scheduling 
data  ( DS24 ) )  are  considered  to  have  been  executed  upon  the  completion 
and  entry  of  this  disposition  into  the  OHMIS  data  base  and  therefore  the 
DS24  data  for  these  tasks  is  deleted  and  the  tasks  are  removed  from  the 
monthly  schedule  data  (DS27)  one  week  following  the  entry  of  the 
disposition  data: 

31.  Date  this  requirement  was  executed. 


32.  Type  of  disposition  of  the  requirement  (i.e.,  fully  completed, 
partially  completed,  aborted,  found  to  be  not  applicable). 

33.  Description  of  what  part  of  this  requirement  was  implemented  if  the 
requirement  was  only  partially  implemented. 

34.  Description  of  the  rationale  for  the  disposition  of  the 
requirement,  if  it  was  not  fully  implemented. 

35.  Employee  identifier  (ID4)  of  the  person  who  executed  the 
requirement. 

36.  Explanation  for  why  the  person  who  actually  executed  the 
requirement  was  not  the  same  as  the  person  who  was  supposed  to 
execute  the  requirement,  if  there  is  a  difference. 

37.  Date  that  the  disposition  of  the  requirement  was  approved,  if 
approval  is  required. 

38.  Employee  identifier  (104)  of  the  person  who  approved  the 
disposition  of  this  requirement. 

39.  Explanation  for  why  the  person  who  actually  approved  the 
disposition  of  the  requirement  was  not  the  same  person  who  was 
supposed  to  have  approved  the  disposition  of  the  requirement,  if 
there  is  a  difference. 


Document  identifiers  (ID3)  or  completed  form  identifier  (ID18) 
for  the  documents,  if  any,  on  which  further  information  on  the 
execution  of  this  requirement  is  contained. 
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Outstanding  Requirements  List 

This  output  lists  selected  data  elements  for  the  requirement 
implementation  data  (DS5)  for  those  requirements  that  have  not  been 
executed,  i.e.,  those  on  the  outstanding  requirements  list  (DL3).  The 
purpose  of  the  output  is  to  provide  the  user  with  a  Summary  list  of  all 
requirements  that  have  been  triggered  but  which  have  not  yet  been 
executed.  This  list  is  generated  daily  to  remind  the  user  of 
outstanding  requirements.  Further  information  on  the  requirement  can  be 
obtained  by  the  user  by  generating  a  Requirement  Notification  and 
Certification  Record  (03)  using  the  requirement  implementation 
identifier  (109)  which  is  given  on  this  output. 

Data  from  this  output  is  obtained  by  reviewing  the  outstanding 
requirements  list  (DL3)  to  identify  the  requirements  that  have  not 
been  executed  and  approved;  referring  to  the  requirements  implementation 
data  (OSS)  for  each  requirement  implementation  identifier  (109)  on  the 
DL3  list  to  identify  the  requirements  specified  by  the  user  (or  by  the 
program  for  'automatic'  04  outputs);  and,  abstracting  the  selected  data 
elements  from  the  DS5  data,  DS1  data,  and  from  the  requirements 
applicability  data  (0S3,  DS4  or  OS 1 7  data)  identified  in  the  DS5  data. 

The  ID9  given  on  the  DL3  list  is  used  to  identify  the  appropriate  DS5 
data;  the  OSS  data  is  used  to  locate  the  appropriate  requirement 
description  data  (0S1)  used  in  this  output,  based  on  the  requirement 
identifier  (ID6)  given  in  the  DS5  data;  the  requirement  application 
identifier  (105)  given  in  the  OSS  data  is  used  to  locate  the 
requirements  app 1 icab i  1 i ty  data  for  either  information  triggered 
requirements  (DS3),  date  triggered  requirements  ( DS 4)  or  allowable 
limits  triggered  requirements  (DS17)  used  in  the  output. 

Generation  of  the  Output:  Most  of  the  04  data  is  obtained  from  the 
requirements  implementation  data  (DS5).  The  output  is  generated  in  two 
ways : 

1)  1  Automatical ly'  (see  Function  F1A):  A  series  of  04  lists 

covering  all  outstanding  requirements  on  the  D13  list  for  the 
OhMIS  service  area  is  generated  each  day  that  the  OHMIS  Data 
Processing  Staff  person  for  that  OHMIS  service  area  logs  onto 
the  OHMIS  system.  The  log  on  program  keeps  track  of  the  last 
date  on  which  the  04  list  was  generated  and  compares  it  with 
the  current  date  each  time  a  user  with  an  OHMIS  user 
identifier  (ID13)  that  is  for  a  OHMIS  Data  Processing  Staff 
type  of  user  (CT1)  for  the  OHMIS  service  area  ( 1 D 10 )  enters 
the  system.  The  series  of  04  outputs  generated  at  this  time 
are  all  for  the  OHMIS  service  area  identifier  (1010)  to  which 
the  Data  Processing  Staff  person  entering  the  OHMIS  system 
belongs. 


The  series  of  04  outputs  automatically  generated  at  this  time 
includes  a  separate  04  listing  for  all  of  the  outstanding 
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requirements  for  each  employee  identifier  { ID4)  who: 

o  Is  responsible  for  the  execution  of  one  or  more 

outstanding  requirements  that  have  not  been  executed  or 
approved. 

o  Is  responsible  for  supervising  (managing)  one  or  more 
requirements  that  have  not  been  executed  or  approved. 

o  Is  responsible  for  approving  one  or  more  requirements 
that  have  been  executed  but  not  been  approved. 

These  lists  are  then  distributed  by  the  OHMIS  Data  Processing 
Staff  to  the  employee  having  the  employee  identifier  (ID4)  for 
which  the  output  was  generated. 

Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
1.5.2.  Requests  for  this  type  of  output  can  be  for  several 
subsets  of  the  requirements  listed  on  the  DL3  lists,  including 
an  Outstanding  Requirements  List  (04)  for  all  outstanding 
requirements  that: 

o  Are  for  a  given  OHMIS  service  area  (1010) 

o  Were  triggered  (i.e.,  the  requirements  implementation 

data  (DS5)  which  generated)  between  a  specified  range  of 
dates 

o  Have  as  given  requirement  type  code  (CT3).  From  the  DS1 
data. 

o  Are  supposed  to  be  executed  by  a  given  OHMIS  user  type 
(CT1)  or  position  type  (CT2).  From  the  DS1  data. 

o  Are  supposed  to  be  executed  by  a  given  OHMIS  user 

identifier  (ID13)  or  position  identifier  ( ID  14 ) .  The  DS5 
data  gives  the  requirement  application  identifier  (ID5) 
for  the  DS3,  DS4  or  DS17  data  containing  the  ID13  or 
1014. 

o  Are  supposed  to  be  executed  by  a  giver  employee 
identifier  (ID4).  From  the  DS5  data. 

o  Same  as  the  above  three  selection  criteria  except  for  the 
person  who  is  supposed  to  have  supervised  or  managed  the 
execution  of  the  requirement  (i.e.,  receive  notice  about 
the  requirement). 

o  Same  as  the  above  three  selection  criteria  except  for  the 
person  who  is  supposed  to  approve  the  disposition  of  the 
requirement. 
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TITLE:  Outstanding  Requirements  List 


1.  Instructions  on  how  to  use  this  output. 

2.  Date  output  generated. 

3.  Type  of  person  for  whom  this  list  was  generated,  i.e.,  the  output 
should  indicate  for  which  of  the  following  four  types  of  persons 
this  is  a  list  of  Outstanding  Requirements:  1)  The  person  who  is 
supposed  to  execute  the  requirements  on  the  list;  2)  the  person 
who  is  supposed  to  supervise  or  manage  the  execution  of  the 
requirements  listed;  3)  the  person  who  is  supposed  to  approve  the 
disposition  of  the  requirements  listed;  or,  4)  none  of  the  above. 
The  answer  is  '4',  if  this  output  was  generated  at  the  request  of 
the  user,  i.e.,  not  automatically  and  the  user  did  not  specify  that 
the  list  was  supposed  to  be  for  a  given  type  of  person. 

4.  If  the  answer  to  the  above  was  other  than  '4‘,  the  identity  and 
mailing  address  of  the  person  for  whom  this  list  was  generated. 

The  identity  includes  the  OHMIS  user  type  code  (CT1)  (or  position 
type  code  (CT2)),  user  identifier  (ID13)  (or  positions  identifier 
(ID14)),  employee  identifier  (ID4)  and  name.  The  name  and  mailing 
address  is  obtained  frum  the  current  user/position  identity  and 
address  data  (D39)  corresponding  to  the  employee  identifier  (ID4) 
given  in  the  DS5  data. 

5.  OHM IS  service  area  identifier  (ID10)  for  which  this  is  a  list  of 
Outstanding  Requirements.  This  identifier  can  be  specified  by  the 
user,  when  the  user  generates  this  output  as  a  part  of  Menu 
Selection  Sequence  1.5.2.  If  no  OHMIS  service  area  is  specified, 
the  program  generates  the  output  for  the  OHMIS  service  area  to 
which  the  OHMIS  user  identifier  (ID13)  entered  at  the  beginning  of 
the  program  sequence  (i.e.,  when  'logging  on')  belongs,  as 
determined  by  the  OHMIS  user/position  by  service  area  list  (DL6). 
For  'automatic'  generations  of  the  04  lists  (i.e.,  for  the  output 
generated  when  the  OHMIS  Data  Processing  Staff  person  logs  on; 
Function  F1A),  the  program  determines  the  OHMIS  service  area  based 
on  the  OHMIS  user  identifier  (ID13)  entered  at  the  beginning  of  the 
'log  on '  sequence . 

6.  Range  of  dates  for  which  the  outstanding  requirements  are  listed, 
i.e.,  the  time  period  during  which  the  requirement  must  have  been 
triggered  (i.e.,  the  requirements  implementation  data  (DS5) 
generated)  for  the  requirement  to  be  listed  on  this  output.  Time 
period  is  specified  by  the  user.  In  automatic  outputs  the  range  of 
dates  is  'all'. 

The  requirement  type  code  (CT3)  of  the  requirements  listed  on 
this  output,  as  specified  by  the  user.  Output  would  read  'all1, 


7. 
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if  not  specified  or  if  this  is  an  automatic  generation  of  the  04 
list. 

8.  The  requirement  identifier  (ID6)  for  the  requirements  listed  in 
this  output,  as  specified  by  the  user;  could  read  'all'  if  not 
specified  or  if  this  is  an  automatic  output. 

9.  The  OHMIS  user  type  (CT1)  or  position  type  (CT2)  and  it's 
associated  OHMIS  user  identifier  (ID13)  or  position  identifier 
(ID14)  and/or  employee  identifier  (ID4)  of  the  person  who  is 
supposed  to  execute  the  requirements  listed  in  this  output.  For 
outputs  generated  by  the  user  as  a  part  of  Menu  Selection  Sequence 
1.5.2,  this  code  and  identifier  information  can  be  specified  by  the 
user,  in  which  case  the  output  could  be  ’All1 2 3.  When  the  output  is 
generated  'automatically1  as  a  part  of  the  'log  on'  program 
sequence,  the  program  automatically  generates  separate  outputs 

for  each  of  the  employee  identifiers  (ID4)  for  whom  there  are 
outstanding  requirements  at  the  time  that  the  output  is  generated, 
i.e.,  requirements  that  have  not  been  executed,  or,  if  they  have 
been  executed,  they  have  not  been  approved  (as  determined  from 
the  DS5  data) . 

10.  Same  as  above  for  the  person  who  is  supposed  to  supervise  the 
execution  of  the  requirement,  i.e.,  the  management  person 
identified  as  responsible  for  reviewing  outstanding  requirements 
and  ensuring  that  they  are  completed,  if  any  such  management  person 
was  specified.  Only  requirements  that  have  not  been  executed  and 
not  been  approved  are  listed. 

11.  Same  as  above  except:  1)  It  is  for  the  person  who  is  supposed  to 
approve  the  disposition  of  the  requirement;  and,  2)  The  program 
'automatically'  generates  a  separate  04  output  for  only  those 
outstanding  requirements  that  require  approval  of  the  disposition 
of  the  requirement  and  have  been  executed,  but  have  not  been 
approved  (as  determined  from  the  DS5  data). 

12.  Seven  columns  of  data  listing  the  following  selected  data 
elements  for  all  of  the  specified  outstanding  requirements,  i.e., 
all  requirements  that  meet  the  specifications  described  in  the 
above  portion  of  tnis  output: 

1)  Requirement  implementation  identifier  (ID9).  From  the  0L3 
list. 

2)  Date  that  the  requirement  was  triggered.  From  the  0S5  data. 

3)  Date  that  this  requirement  is  due.  This  is  for  date 
triggered  requirements  only.  The  above  date  triggered  is 
the  date  on  which  the  DS5  data  was  generated,  i.e.,  the  date 


that  the  requirement  is  due  minus  the  ‘prior  notification 
time',  i.e.,  the  'next  suspense  dat°'.  The  date  due  given  in 
this  column  of  the  output  is  the  date  that  the  requirement  is 
due,  i.e.,  the  ‘next  suspense  date'  plus  the  'prior 
notification  time' .  From  the  DS5  data. 

Recommended  length  of  time  to  complete  the  requirement  from 
the  date  due.  From  the  DS1  data. 

Requirement  identifier  (ID6).  From  the  DS5  data. 

Brief  description  of  this  requirement.  From  the  DS1  data. 

Task  identifier  (ID23)  for  the  task  that  was  initiated  by 
this  requirement,  if  any.  From  the  list  of  task  identifiers 
(  1023)  by  requirement  implementation  identifiers  ( ID 9 )  and  by 
0HM1S  service  area  (0L38). 


OUTPUT  05:  Description 


Reminder  Notice  List 


This  output  lists  all  reminders  that  have  been  triggered,  but  not 
executed  as  of  the  current  date  for  a  given  0HM1S  service  area  ( 1010 ) 
and  person  responsible  for  executing  the  reminder.  The  output  is 
generated  from  Reminder  Notice  type  of  suspense  data  (DS4).  Reminder 
Notices  are  actions  that  the  user  wishes  to  be  reminded  of  but  which  are 
not  based  on  any  requirement  or  recommendation,  i.e.,  are  not  linked  to 
any  requirement  description  data  (DS1).  This  type  of  suspense  data  is 
handled  in  the  same  way  as  requirements  suspense  data  as  far  as 
processing,  but  no  historical  data  is  maintained,  i.e.,  both  the 
suspense  data  (DS4)  and  the  requirement  implementation  data  (DS5)  are 
deleted  as  soon  as  the  date  and  type  of  disposition  of  the  reminder  is 
entered  into  the  OHMIS  data  base.  Also,  separate  Notices  (i.e.,  output 
03)  are  not  generated  for  each  reminder  item,  as  they  are  for  each 
requirement  type  suspense  data  item;  instead,  the  user  receives  a  list 
(the  Reminder  Notice  List  (05))  which  provides  a  description  of  all 
reminders  that  have  been  triggered  (by  reaching  the  specified  suspense 
date)  as  of  the  current  date. 

Generation  of  Output:  Most  of  tne  data  on  the  05  list  is  obtained 
from  the  requirement  implementation  data  (DS5),  using  the  reminder 
notice  list  (DL9)  to  identify  those  DS5  data  sets  that  are  for  Reminder 
Notice  type  of  suspense  implementation  data.  The  output  is  generated  in 
two  ways : 

1)  1  Automatical  1 y '  (see  Function  F 1 A ) :  A  series  of  05  lists 

covering  all  outstanding  Reminder  Notices  in  the  DS5  data  is 
generated  each  day  that  the  OHMIS  Data  Processing  Staff  person 
logs  on  to  the  OHMIS  system.  Outstanding  Reminder  Notices  are 
those  that  have  been  triggered,  i.e.,  those  for  which  Reminder 
Nutice  type  of  DS5  data  has  been  generated,  but  which  have  not 
been  executed;  as  only  current  data  is  maintained  for  Reminder 
Notice  type  implementation  data,  outstanding  Reminder  Notice 
data  would  include  al 1  DS5  data  that  is  for  Reminder  Notices 

(as  distinguished  from  DS5  data  that  is  for  requirements 

suspense  data)  as  of  the  current  date.  The  OHMIS  log  on 
program  keeps  track  of  the  last  date  in  which  the  05  list  was 

generated  for  an  OHMIS  service  area  and  compares  this  date 

with  the  current  date  each  time  a  user  with  an  OHMIS  user 
identifier  (ID13)  that  is  for  a  OHMIS  Data  Processing  Staff 
type  of  user  (CT1)  for  the  service  area  enters  the  system. 

The  series  of  05  outputs  generated  automatically  at  this  time 
are  all  for  the  OHMIS  service  area  (ID10)  to  which  the  Data 
Processing  Staff  user  entering  the  system  belongs.  The  05 
list  series  includes  a  separate  05  list  of  Reminder  Notices 
for  each  anployee  identifier  (ID4)  who  currently  has  one  or 
more  outstanding  Reminder  Notices  for  which  he/she  is 
responsible,  i.e.,  for  which  he/she  is  the  person  whom  is  to 


execute  the  action  given  in  the  Reminder  Notice.  Each  05  list 
in  this  series  is  distributed  by  the  Data  Processing  Staff  to 
the  employee  having  the  employee  identifier  (ID4)  for  which 
the  list  was  genei  ated. 

2)  Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
1.5.4.  Requests  of  this  type  can  either  be  a  list  of  all 
Reminder  Notices  for  an  OHMIS  service  area  ( I DIO )  (in  which 
case  the  output  would  be  the  complete  series  of  05  lists  for 
the  OHMIS  service  area);  or,  for  all  Reminder  Notices  for  a 
given  employee  identifier  (ID4)  who  is  responsible  for  the 
execution  of  the  action  given  in  the  Reminder  Notice. 

Data  for  the  05  output  is  obtained  by  reviewing  the  reminder  notice  list 
( DL 9) ,  i.e.,  the  list  identifying  the  requirement  implementation  data 
(DS5)  for  the  Reminder  Notice  type  of  implementation  data;  identifying  a 
requirement  implementation  identifier  (ID9)  on  this  list;  locating  the 
requirements  implementation  data  (DS5)  that  corresponds  to  that  ID9; 
and,  abstracting  the  data  elements  listed  on  the  mock  up  for  05.  The 
DS5  data  provides  the  requirement  identifier  (ID6)  which  identifies  the 
requirement  description  data  (DS1)  used  in  this  output;  the  DS5  data 
also  provides  the  requirement  application  identifier  (ID5)  which 
identifies  the  appropriate  date  triggered  requirements  suspense  data 
(DS4). 


TITLE:  Reminder  Notice  List 


Instructions  to  the  user  on  how  to  use  this  output. 

Date  this  output  was  generated. 

The  identity  and  address  of  the  person  who  is  supposed  to  execute 
the  actions  on  this  list.  This  includes  the  OHMIS  user  type  (CT1) 
or  position  type  (CT2)  (from  the  DS1  data)  and  the  associated  OHMIS 
user  identifier  (ID13)  or  position  identifier  (ID14)  (from  the  DS4 
data)  and  the  employee  identifier  (ID4)  (from  the  DS5  data)  for  the 
person  who  is  supposed  to  execute  the  actions  listed  in  this 
Requirement  Notice  List  (05).  It  also  includes  the  name  and 
address  of  this  person.  This  information  is  obtained  from  the 
current  user/position  identity  and  address  data  (DS9)  corresponding 
to  the  employee  identifier  (ID4)  given  in  the  DS5  data. 

The  user/position  code  and  identifier  information  can  be  specified 
by  the  user,  in  which  case,  the  output  could  read  'All',  if  none  is 
specified.  When  the  output  is  generated  automatically  as  a  part  of 
the  log  on  program  sequence,  the  program  automatically  generates 
separate  outputs  for  each  of  the  employee  identifiers  (ID4)  for 
whom  there  are  outstanding  reminder  notices  at  the  time  that  the 
output  is  generated. 

OHMIS  service  area  identifier  (ID10)  for  which  this  is  a  list  of 
outstanding  Reminder  Notices.  This  identifier  can  be  specified  by 
the  user,  when  the  user  generates  an  05  list  as  a  part  of  Menu 
Selection  Sequence  1.5.4;  if  no  service  area  is  specified,  the 
program  generates  the  output  for  the  OHMIS  service  area  to  which 
the  OHMIS  user  identifier  (ID13)  entered  at  the  beginning  of  the 
program  sequence  belongs  (as  determined  from  the  OHMIS  user 
identifier  by  service  area  list  (DL6)).  For  automatic  generations 
of  this  output,  i.e.,  for  the  output  generated  when  the  OHMIS  Data 
Processing  Staff  person  logs  on,  the  program  determines  the  OHMIS 
service  area  based  on  the  OHMIS  user  identifier  (ID13)  entered  at 
the  beginning  of  the  log  on  sequence. 

Seven  columns  of  data  listing  the  following  selected  data 
elements  for  all  of  the  above  specified  outstanding  Reminder 
Notice  actions,  i.e.,  all  those  which  meet  the  specifications  given 
on  the  above  portion  of  this  output: 

1)  Requirement  implementation  identifier  (ID9)  for  this 
particular  implementation  of  the  action.  From  the  DL9  list. 

2)  Requirement  application  identifier  (ID5)  for  the  DS4  data 
that  triggered  this  particular  implementation  of  the  action. 
From  the  DS5  data. 


3)  Date  this  action  was  triggered,  i.e.,  date  that  the 
requirement  implementation  data  (DS5)  was  generated.  From  the 
DS5  data. 

4)  Date  this  action  is  due.  From  the  0S5  data. 

5)  Supplement  to  the  requirement  description.  This  is  the  data 
element  on  the  DS4  data  on  which  the  description  of 
non-requirement  actions  (i.e.,  a  description  of  the  action 
that  the  user  wishes  to  be  reminded  of  by  Reminder  Notice  type 
suspense  data)  is  given. 

6)  Task  identifier  (ID23)  for  the  task,  if  any,  which  was 
initiated  by  the  triggering  of  this  Reminder  Notice.  From  the 
list  of  task  identifiers  (ID23)  by  requirement  implementation 
identifier  (ID9)  and  by  OHMIS  service  area  (DL38). 

7)  Spaces  for  entering: 

a)  The  date  that  the  action  was  executed. 

b)  The  type  of  disposition  of  the  action  (fully  completed, 
partially  completed,  aborted,  found  not  applicable). 

These  two  spaces  on  the  output  provide  a  means  for  the  user  to 
indicate  that  the  action  has  been  executed.  These  two  data 
elements  are  then  entered  onto  the  requirements  implementation 
data  (DS5)  using  Menu  Selection  Sequence  1.5.3  (Function  FZB) 
at  which  time  the  requirements  implementation  data  (DS5)  is 
deleted.  Also,  if  the  'next  suspense  date'  on  the  DS4  data 
that  generated  the  action  is  greater  than  the  'last  suspense 
date',  then  the  DS4  data  is  deleted  at  this  time. 


OUTPUTS  06  -  08 


Examples  of  User  Requested  Outputs 


Outputs  06  through  08  consist  of  the  Vacant  Job  Class  List  (06),  the 
Potential  New  Hire  List  (07)  and  the  New  Hire  List  (08).  These 
outputs  are  different  from  the  other  outputs  referred  to  in  this 
report,  because  these  are  not  standard  program  management  outputs  or 
outputs  that  are  generated  automatically  as  a  part  of  the  execution  of 
the  core  OHMIS  data  processing  functions.  Instead,  these  three 
outputs  are  examples  of  user  requested  outputs  that  are  generated 
through  a  user  query  of  specific  data  elements  of  the  data  base 
generated  through  OHMIS. 

Although  the  storage  and  file  structure  of  OHMIS  has  not  been  finally 
defined,  it  is  conceived  as  a  Data  Base  Management  System  type  of 
structure.  This  means  that  the  user  will  be  able  to  make  requests  for 
outputs  consisting  of  data  elements  specified  by  the  user.  These  data 
elements  will  include  most  of  the  data  elements  on  the  OHMIS  data  base 
and  the  outputs  will  include  the  capability  to  select  from  a  wide 
variety  of  output  formats  for  various  combinations  of  these  data 
elements. 

Outputs  06  through  08  are  three  examples  of  such  user  requested 
outputs.  These  examples  were  used  in  the  discussion  of  the  11  core 
data  processing  functions.  These  outputs  correspond  to  three  Data 
Lists,  which  were  also  used  as  examples.  The  Data  Lists  are  examples 
of  temporarily  generated  files  created  at  the  request  of  the  user. 

The  three  Data  Lists  consist  of  the  vacant  job  class  list  (DL1 )  which 
corresponds  to  Output  06,  the  potential  new  hire  list  (DL2)  which 
corresponds  to  Output  07,  and  the  new  hire  list  (DL4)  which  corre¬ 
sponds  to  Output  08.  In  the  examples  given  for  the  use  of  OHMIS,  it 
is  assumed  that  these  Data  Lists  may  be  formed  by  the  user  as  a  part 
of  the  process  of  hiring  new  civilian  employees.  Lists  of  this  type 
would  be  used  by  the  occupational  health  program  activity  as  a  work 
aid  to  facilitate  the  performance  of  functions  requiring  information 
about  new  employees.  The  lists  would  consist  of: 

o  DL1:  Vacant  job  class  list.  This  would  be  a  list  of  job 
class  identifiers  (ID7s)  for  those  jobs  for  which  the 
Civilian  Personnel  Office  (CP0)  is  actively  looking  for  a 
new  employee.  The  occupational  health  program  activity  may 
wish  to  have  such  a  list  in  order  to  ensure  that  the 
information  about  the  potential  hazards  to  which  employees 
in  the  job  class  for  which  new  employees  are  being  hired  is 
current  and  complete.  Such  verification  of  currency  of 
hazards  data  by  job  class  would  be  recommended  as  a  routine 
part  of  the  inprocessing  of  new  employees.  The  generation 
of  a  list  such  as  DLl  would  assist  the  occupational  health 
activity  managers  in  performing  this  function. 
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DL2;  Potential  new  hire  list.  This  would  be  a  list  of 
employee  identifiers  (ID4s)  for  employees  that  are  tenta¬ 
tively  hired,  i.e.,  have  been  through  most  CPO  processing 
but  for  whom  all  of  the  pre-employment  occupational  health 
services  (e.g.,  preplacement  physicals)  have  not  yet  been 
performed.  The  Occupational  Health  Nurse  may  wish  to 
generate  such  a  list  as  a  daily  checklist  of  persons  for 
whom  pre-employment  services  need  to  be  performed. 

o  DL4:  New  hire  list.  This  would  be  a  list  of  employee 
identifiers  (ID4s)  for  employees  that  have  recently  been 
hired.  The  occupational  health  program  activity  may  wish  to 
generate  such  a  list  to  use  as  a  checklist  for  occupational 
health  services  needed  by  new  employees,  such  as  selection 
of  and  fitting  for  personal  protective  equipment,  setting  up 
routine  medical  surveillance,  etc. 

In  each  of  the  above  three  examples,  the  data  from  the  Data  Lists 
would  be  received  from  the  CPO  for  the  individual  OHMIS  Service  Area 
on  a  routine  (e.g.,  daily)  basis.  The  Outputs  (06  through  08) 
corresponding  to  these  lists  would  consist  of  a  "dump"  of  the  Data 
Lists  showing  the  job  class  of  employee  identifiers  on  the  particular 
list  as  of  a  given  date.  Through  a  query  of  the  data  base  management 
system  in  OHMIS,  the  user  could  generate  such  an  output  at  any  time  by 
specifying  the  data  elements  required  and  the  time  period  (date) 
desired.  Generation  of  other  data  lists  and  their  corresponding 
outputs  would  be  done  in  a  similar  way. 

It  is  expected  that  the  OHMIS  Users’  Procedures  Manual  (as  described 
in  Section  6.1)  will  contain  many  examples  of  recommended  types  of 
special  temporary  data  lists  and  user  requested  outputs.  Although 
these  outputs  are  generated  at  the  request  of  the  user,  recommenda¬ 
tions  for  appropriate  user  requested  outputs  should  be  included  in  the 
OHMIS  Users'  Procedures  Manual  because  such  outputs  can  act  as  "work 
aids"  in  the  operation  of  the  occupational  health  program  activity. 

The  use  of  such  standard  outputs  by  all  installations  would  increase 
the  efficiency  and  consistency  of  the  Army's  occupational  health 
program  operations. 
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OUTPUT  09:  Description 


Generation  of  Output:  Most  of  the  09  data  is  generated  from  the 
allowable  limits  check  request  data  (DS18).  The  output  is  generated  by 
the  user  through  Menu  Selection  Sequence  4.4.1.  Requests  for  this  type 
of  output  can  be  for  several  subsets  of  allowable  limits  check  request 
data  (0S18),  including: 

o  All  09  outputs  for  a  given  OHMIS  service  area  identifier 

(1010);  the  1010  is  on  the  DS18  data.  As  DS18  data  is  only 
kept  for  outstanding  allowable  limits  checks  (i.e.,  those 
checks  that  have  not  yet  been  conducted),  this  selection 
criteria  for  this  output  would  yield  all  Allowable  Limits 
Check  Notices  for  uncompleted  allowable  checks  applicable  to  a 
given  OHMIS  service  area. 

o  A  specific  Allowable  Check  Notice  as  specified  by  the  user 
using  the  allowable  limits  check  request  identifier  (1022) 
which  is  obtained  by  the  program  from  the  0S18  data  and 
provided  to  the  user  on  the  Outstanding  Allowable  Limits 
Checks  Needed  List  (010). 

o  The  09  outputs  for  all  allowable  limit  check  request  (DS18 
data)  triggered  between  a  specified  range  of  dates.  The  date 
on  which  the  DS18  data  was  generated  is  given  on  the  DS18 
data. 

Tne  data  for  the  09  output  is  obtained  from  the  DS18  data  for  the 
particular  allowable  limits  check  request  identifier  (1022)  shown  on  the 
output  mock  up  unless  otherwise  specified. 


OUTPUT  09:  Mock  Up 


TITLE:  Allowable  Limits  Check  No t i c e 


1.  Instructions  to  the  user  on  how  to  use  this  output.  Includes  how 
to  execute  an  allowable  limits  check  (Menu  Selection  Sequence 
4.4.4).  If  this  is  a  missing  allowable  limits  applicability  values 
type  of  allowable  limits  check,  the  instructions  should  tell  the 
user  to  have  the  values  for  the  data  elements  listed  below 
available  when  conducting  the  allowable  limits  check.  These 
instructions  are  the  same  for  all  09  outputs. 

2.  Allowable  limits  check  request  identifier  (ID22)  for  this  Notice. 

3.  Date  this  allowable  limits  check  request  was  triggered  (date  the 
DS18  data  was  generated). 

4.  QHMIS  service  area  identifier  ( I  DIO )  from  which  this  allowable 
limits  check  request  originated. 

5.  Statement  as  to  whether  an  allowable  limits  check  was  originated 
because:  1)  There  are  missing  allowable  limits  applicability 
values  needed  to  determine  which  allowable  limits  are  applicable; 
or,  2)  the  potentially  applicable  allowable  limits  identified 
require  a  manual  check  to  determine  if  they  match  the  corresponding 
values  on  the  OHMIS  form  (i.e.,  the  DS14  data)  the  entry  of  which 
initiated  the  allowable  limits  evaluation  which  triggered  this 
allowable  limits  check  request.  The  DS18  data  indicates  what  type 
of  allowable  limits  check  request  this  is. 

6.  Whether  this  allowable  limits  check  is  for:  1)  The 
form-as-a-whole;  or,  2)  a  set  of  forms  subpart  data  (DS1I).  (See 
explanation  for  these  two  types  of  allowable  limits  checks  given  in 
the  descriptions  prefacing  the  forms  specification  data  set  (DS10) 
and  the  allowable  limits  specification  data  set  (DS17).) 

7.  The  completed  forms  identifier  (ID18)  for  the  set  of  completed 
forms  data  (i.e.,  the  entry  from  an  OHMIS  form  of  a  set  of  DS14 
data)  the  entry  of  which  triggered  this  allowable  limits  check 
request. 

8.  The  form  type  code  (CT9)  and  vocabulary  word  describing  this  type 
of  form  for  the  above  referenced  1018 .  The  CT9  is  on  the  DS 14  data 
referenced  by  the  above  1018 .  The  vocabulary  word  for  this  type 
code  is  on  the  OHMIS  system  vocabulary  words/phrase  data  base. 

9.  Forms  specification  identifier  (ID16)  for  the  version  of  the  form 
used  in  the  above  referenced  DS14  data. 

10.  Forms  subpart  identifier  (IDI7)  for  the  particular  part  of  the 
form,  if  any,  covered  by  this  allowable  limits  check  request.  If 
this  an  allowable  limits  check  request  for  a  form-as-a-whole,  this 
data  element  would  be  left  blank. 


OUTPUT  09:  Mock  Up 


The  data  element  types  and  values  for  the  up  to  6  forms  units  (up 


to  9  forms  units  for  a  forms-as-a-whole  allowable  limits 
evaluation)  entered  onto  the  above  referenced  DS14  data.  Includes 
an  identification  of  which  of  these  forms  unit  values  are  to  be 
used  in  evaluating  allowable  limits.  The  forms  unit  values  are 
numbered  from  1  to  6  (or  1  to  9)  so  that  the  user  may  know  which 
forms  units  are  referred  to  in  the  allowable  limits  specification 
data  (DS17)  and/or  the  allowable  limits  applicability  factors  and 
values  data  (DS15  and  DS16). 

The  data  element  types  for  each  of  the  up  to  5  allowable  limits 


applicability  factors  for  each  of  the  up  to  6  (or  up  to  9)  form s 
units  identified  above  for  which  the  OHMIS  data  base  was  missing 
values  at  the  time  that  the  allowable  limits  evaluation  was 
conducted.  There  would  be  no  such  data  element  types,  if  this 
allowable  limits  check  request  is  to  manually  evaluate  allowable 
limits  already  identified  as  potentially  applicable. 

The  values  for  the  up  to  6  data  element  types  entered  onto  the 


DS14  data  (completed  form)  referenced  above  for  the  forms  subpart 
identifier  (ID17),  referenced  above,  i.e.,  the  values  the  entry  of 
which  triggered  the  allowable  limits  evaluation  from  which  this 
allowable  limits  check  request  originated.  If  this  is  an  allowable 
limits  check  for  the  form-as-a-whole ,  this  would  be  blank. 

The  requirement  application  identifier  (ID5)  for  the  set  of 
allowable  limits  specification  data  (DS17)  found  to  be  applicable 
but  which  requires  a  manual  allowable  limits  evaluation.  If  this 
is  an  allowable  limits  check  for  missing  allowable  limits 
applicability  values,  this  identifier  would  be  left  blank. 

The  description  of  the  above  referenced  allowable  limits 
specification.  From  the  0S17  data  for  the  above  ID5.  The  user  may 
use  this  description  and  the  above  values  data  entered  on  the  DS14 
data  to  make  the  manual  allowable  limits  evaluation.  If  the  user 
feels  more  information  is  needed,  the  09  output  provides  the  user 
with  the  identifiers  of  the  form  and  allowable  limits 
specifications  needed  to  obtain  further  information. 


OUTPUT  OIQ:  Description 


Outstanding  Allowable  Limits  Checks  Needed  Lists 


This  output  lists  selected  data  elements  from  the  allowable  limits  check 
request  data  (DS18)  for  all  allowable  limits  check  requests  made  for  a 
given  OriMIS  service  area.  The  purpose  of  this  output  is  to  provide  the 
user  with  a  surunary  list  of  the  allowable  limits  check  requests  that 
have  been  triggered  by  the  user  having  entered  completed  forms  data 

(DS14)  of  a  type  for  which  an  allowable  limits  evaluation  (part  of 

Function  F3B)  could  not  be  completed.  The  list  is  generated  daily  and 
thus  acts  as  a  check  list  telling  the  user  of  allowable  limits  checks 
that  need  to  be  made.  Because  the  allowable  limits  check  request  data 
(DS18)  is  deleted  when  the  allowable  limits  check  (Menu  Selection 
Sequence  4.4.4;  Function  F3C)  is  executed,  there  is  data  in  the  OHMIS 
data  base  for  only  uncompleted  allowable  limits  checks. 

Generation  of  Output:  Most  of  the  010  data  is  obtained  from  the 
allowable  limits  cneck  request  data  (DS18).  The  output  is  generated  in 
two  ways : 

1)  ‘Automatical ly 1  (see  Function  F1A) :  the  complete  010  list 

(i.e.,  covering  al 1  allowable  limits  check  request  data 

(0S18)  for  an  OHMIS  service  area  ( ID10 ) )  is  generated  once 
each  day  that  the  OHMIS  Data  Processing  Staff  person  for  the 
service  area  logs  on  to  the  OHMIS  system.  (The  log  on  program 
keeps  track  of  the  last  date  on  which  the  03  list  was 
generated  and  compares  it  with  the  current  date  each  time  the 
user  with  an  OHMIS  user  identifier  (ID13)  that  is  for  an  OHMIS 
Data  Processing  Staff  type  of  user  (CT1)  enters  the  system  for 
a  given  OHMIS  service  area.  The  list  is  generated  for  the 
OHMIS  service  area  identifier  (ID10)  associated  with  the  OHMIS 
user  logging  on  to  the  system,  using  the  OHMIS  user  identifier 
by  service  area  list  (DL6). 

2)  Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
4.4.2.  The  user  may  specify  that  this  output  includes: 

o  All  allowable  limits  check  request  for  a  service  area 
(1010).  The  1010  is  on  the  DS Id  data. 

o  All  allowable  limits  check  request  generated  between  a 
specified  range  of  dates.  The  date  generated  is  on  the 
DS18  data. 

o  All  allowable  limits  checks  for  a  given  allowable  limits 
specification,  i.e.,  for  a  given  requirement  application 
identifier  (ID5)  as  specified  on  some  DS18  data  sets, 
i.e.,  those  DS IS  data  sets  that  are  requests  for  manual 
checks  of  allowable  limits  specification  already 
identified  as  applicable. 
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Data  for  this  output  is  obtained  from  the  allowable  limits 
check  request  data  (DS18)  unless  otherwise  specified  on  the 
mock  up. 
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OUTPUT  010:  Mock  Up 

TITLE:  Outstanding  Allowable  Limits  Checks  Needed  Lists 


1.  Instructions  to  the  user  on  how  to  use  this  output.  Includes 
telling  the  user  to  use  this  suimary  to  obtain  the  complete 
information  on  an  allowable  limits  check  request  by  generating  the 
Allowable  Limits  Check  Notice  (09)  for  the  allowable  limits  check 
request  identifier  (1022)  given  on  this  list. 

2.  Date  this  output  was  generated. 

3.  OHMIS  service  area  identifier  ( I  DIO )  for  which  this  is  a  list  of 
allowable  limits  checks  needed.  This  identifier  is  specified  by 
the  user;  or,  for  automatically  generated  010  outputs,  determined 
by  the  program  based  on  the  OHMIS  user  identifier  (ID13)  entered  at 
the  beginning  of  the  log  on  program  sequence  in  which  this  output 
was  generated. 

4.  Range  of  dates  for  the  time  period  covered  by  the  allowable 
limits  check  requests  listed,  i.e.,  the  time  period  between  which 
an  allowable  limits  check  request  needs  to  have  been  triggered  for 
it  to  be  listed  on  this  particular  09  output.  Specified  by  the 
user.  The  output  would  read  'AH',  if  not  specified  by  the  user  or 
if  this  output  was  automatically  generated. 

5.  Requirement  application  i.-gntifier  (ID5)  for  which  this 
constitutes  a  list  of  requirements  checks  needed.  Specified  by  the 
user.  The  output  wou i  :  read  'All',  if  none  specified  by  the  user 
or  if  this  is  an  automatically  generated  output. 

6.  Four  columns  of  data  listing  the  following  selected  data  elements 
for  all  specified  allowable  limits  check  request  data  (DS18), 
i.e.,  all  DS18  data  meeting  the  specifications  of  the  user: 

1 )  Allowable  limits  check  request  identifier  (ID22). 

2)  Date  on  which  the  allowable  limits  check  request  was 
triggered. 

3)  Form  type  code  (CT9)  for  the  type  of  form  for  which  data  was 
entered  which  triggered  this  allowable  limits  check  request. 
The  CI9  comes  from  the  completed  forms  data  (DS14)  for  the 
completed  forms  identifier  (ID18)  on  the  DS18  data  referenced 
by  the  IU22  in  the  corresponding  first  column  on  this  output. 

4)  The  vocabulary  word/phrase  corresponding  to  the  above  form 
type  code  (CT9).  This  vocabulary  data  comes  from  a  OHMIS 
vocabulary  word/phrase  data  base. 
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OUTPUT  Oil:  Description 


Allowable  Limits  Evaluation  Summary 


This  output  is  used  to  inform  the  user  of  the  results  of  an  evaluation 
for  allowable  limits.  It  is  generated  'automatically'  (without  the 
user's  option)  on  three  occasions: 

1)  When  the  user  completes  the  entry  of  completed  forms  data 
(OSH)  for  an  OHMIS  form  into  the  OHMIS  data  base  (Menu 
Selection  Sequence  3.1).  At  the  completion  of  the  entry  of 
data  on  a  form  the  OHMIS  program  (Function  F3B)  makes  an 
allowable  limits  evaluation.  The  010  output  summarizing  the 
results  of  this  evaluation  is  printed  out  following  this 
evaluation. 

2)  The  above  is  also  true  if  the  user  is  entering  changes  to  the 
DS14  data,  i.e..  Menu  Selection  Sequence  3.3. 

3)  When  the  user  completes  an  allowable  limits  check  (Menu 
Selection  Sequence  4.4.4;  Function  F3C). 

The  010  output  lists  two  types  of  information: 

1)  The  allowable  limits  check  requests,  if  any,  that  were 
generated  as  a  result  of  the  allowable  limits  evaluation  for 
the  form.  These  requests  are  generated  when  the  program  is 
not  able  to  complete  the  allowable  limits  evaluation.  (See 
output  09,  Allowable  Limits  Check  Notice,  for  explanation  of 
allowable  limits  check  requests.) 

2)  The  requirements,  if  any,  that  were  triggered  as  a  result  of 
the  allowable  limits  evaluation.  Requirements  are  triggered 
wnen  the  program  finds  that  the  data  entered  on  an  OHMIS  form 
matches  a  set  of  applicable  allowable  limits  specification 
data  (DS17)  for  the  data  element  type  entered. 

Generation  of  Output:  This  output  is  generated  primarily  from  the 
completed  forms  data  (OSH)  corresponding  to  the  completed  forms 
identifier  (1018)  from  which  this  output  was  initiated;  from  the  list  of 
allowable  limits  check  request  identifiers  (ID22)  by  completed  form 
identifier  ( ID 18 )  and  by  OHMIS  service  area  (DL17)  and  the  corresponding 
allowable  limits  check  request  data  (DS18);  and,  from  the  list  of  active 
(allowable  limits  specification)  requirement  implementation  identifiers 
(105)  by  completed  form  identifier  (ID18)  and  OHMIS  service  area  ( DL 18 ) 
and  the  correspond ing  requirements  implementation  data  (DS5). 

The  Oil  output  is  generated  in  two  ways: 

1)  Automatica I ly  (as  described  above);  and, 


OUTPUT  Oil:  Description 


2)  at  the  request  of  the  user  using  Menu  Selection  Sequence 

4.4.3.  If  the  user  requests  this  output  he  must  specify  the 
completed  form  identifier  (ID18)  for  which  he/she  wishes  the 
output  generated. 


OUTPUT  Oil:  Mock  Up 


TITLE:  Allowable  Limits  Evaluation  Summary 


1.  Instructions  to  the  user  on  the  meaning  of  the  data  elements  on 
this  form. 

2.  OHMIS  service  area  identifier  ( I  DIO )  for  the  service  area  in 
which  the  form  which  initiated  this  evaluation  of  allowable  limits 
originated. 

3.  Date  this  output  was  generated. 

4.  Completed  form  identifier  (ID18)  for  the  set  of  completed  forms 
data  (DS14)  for  which  this  output  is  a  summary  of  the  allowable 
limits  evaluation. 

5.  Form  type  code  (CT9)  and  vocabulary  words/phrase  description  of 
the  form  type  to  which  the  above  ID18  refers.  The  CT9  comes  from 
the  above  referenced  DSI4  data.  The  vocabulary  word/phrase 
description  for  this  type  code  (i.e.,  in  this  case,  the  general 
title  of  the  form)  comes  from  the  OHMIS  vocabulary  word/phrase  data 
base. 

6.  Date  the  above  referenced  DS14  data  was  completed.  From  the  DS14 
data . 

7.  Values  for  the  up  to  9  forms  units  on  the  above  referenced 
completed  form,  i.e.,  on  the  DS 14  data. 

8.  Subinstructions  telling  the  user  that  the  following  are  the 
allowable  limits  check  request  identifiers,  if  any,  for  the 
allowable  limits  checks  that  still  remain  unexecuted  for  the  data 
entered  on  the  above  form. 

9.  A  listing  of  each  of  the  allowable  limits  check  request  identifiers 
(ID22)  on  the  list  of  allowable  limits  check  revest  identifiers  by 
completed  form  identifier  and  by  OHMIS  service  area  ( DL 1 7 )  that  are 
for  the  above  referenced  completed  form  identifier  (ID18). 

10.  Subinstructions  telling  the  user  that  the  following  are: 

1)  The  requirement  implementation  identifier  (ID9)  for  the 
requirements  that  were  triggered  by  a  finding  during  the 
allowable  limits  evaluation  that  allowable  limits  had  been 
met,  if  the  requirement  has  not  yet  been  executed; 

2)  the  identifier  for  the  requirement  triggered;  and. 


3)  the  identifier  for  the  allowable  limits  specification  data 
wMch  was  found  to  match. 
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This  subinstruction  tells  the  user  that  there  may  have  been  no 
requirements  triggered  by  this  allowable  limits  evaluation  (or  that 
they  have  already  been  executed)  and  that,  in  that  case,  no 
identifiers  will  be  listed  below. 

11.  Three  columns  of  data  listing: 

1)  Requirement  implementation  identifier  (ID9).  From  the  DL18 
for  the  above  referenced  completed  form  identifier  (ID18). 

2)  Requirement  identifier  (ID6)  for  the  requirement  listed  on 
the  requirement  implementation  data  (DS5)  for  the  ID9  given  in 
the  first  column. 

3)  (Allowable  limits  specification)  requirement  application 
identifier  (IDS)  for  the  set  of  allowable  limits 
specification  data  ( DS 17)  which  was  found  to  match  the  data 
entered  on  the  above  referenced  form  and  therefore  resulted  in 
the  triggering  of  a  requirement.  From  the  DS5  data  referenced 
by  the  above  ID9. 


OUTPUT  QI2:  Description 


OHMIS  'Blank'  Form  (Generic) 


This  description  and  mock  up  of  an  output  is  provided  to  show  the 
generic  format  that  will  be  used  for  all  OHMIS  'blank'  forms.  It 
corresponds  to  the  completed  forms  data  (DSN)  which  provides  a 
description  of  the  generic  data  set  that  is  used  to  enter  data  from  all 
OHMIS  forms.  OHMIS  will  have  many  different  forms  and  is  designed  to 
allow  the  user  to  add  new  forms  at  any  time.  Some  of  the  expected  major 
types  of  forms  that  will  be  used  in  OHMIS  are  described  in  the  Form 
Type  (FT)  description  section  of  this  report.  Each  type  of  blank  form 
will,  of  course,  look  different  from  all  other  forms,  depending  on  its 
content  (i.e.,  the  data  elements  requested  on  the  form).  However,  all 
forms  will  have  a  common  data  input  format  (shown  in  DS14)  and  a  common 
data  output  format,  shown  here. 

Generation  of  Output.  This  output  is  generated  primarily  from  the 
forms  description  data  (DS10)  which  describes  the  contents  of  a  form. 

The  DS10  data  specifies  the  individual  data  element  types  on  the  form  by 
reference  to  sets  of  forms  subpart  data  (DS11)  and  therefore  DS11  data 
is  also  used  extensively  in  this  output.  Sane  of  the  data  element  types 
in  the  identification  portion  of  a  blank  form  are  completed  by  the 
user  at  the  time  that  the  blank  form  is  generated  (Function  F3A).  This 
data  is  stored  on  the  outstanding  (uncompleted)  forms  monitoring  data 
(DS22)  for  the  form  until  data  from  the  form  has  been  entered  onto  the 
OHMIS  data  base. 

An  012  output  is  generated  during  Function  F3A  (generation  of  blank 
forms  function).  The  user  may  specify  that  he/she  wishes  only  to 
examine  a  blank  form,  i.e.,  examine  forms  description  data  (Menu 
Selection  Sequence  2.1.4);  or,  the  user  may  wish  to  generate  a  form  for 
the  purposes  of  entering  data  onto  the  form  (Menu  Selection  Sequence 
2.1.5).  If  the  former,  the  012  output  is  completely  blank  (except  for 
the  completed  form  identifier  ( ID18 ) )  and  contains  only  information  on 
the  DS10  and  0S11  data  (i.e.,  not  the  DS22  data).  If  the  later,  the 
user  is  asked  to  supply  some  of  the  identification  portions  of  the 
data  on  the  form  at  the  time  that  the  form  is  generated;  this  data  is 
stored  on  the  DS22  data  and  is  called  on  in  the  012  output  generated  at 
the  end  of  Function  F3A. 

The  user  may  also  request  a  copy  of  a  form  that  has  already  been 
previously  generated,  i.e.,  a  form  for  which  he/she  has  already  provided 
the  identification  information  (Menu  Selection  Sequence  2.1.5).  The  012 
output  with  the  completed  identification  information  is  also  portrayed 
on  the  data  entry  screen  when  the  user  indicates  that  he/she  is  ready  to 
enter  data  for  this  form  (Menu  Selection  Sequence  3.1;  Function  F3B) . 

The  012  format  is  also  used  to  provide  the  description  and  mock  up  of 
the  output  that  would  be  generated  when  a  user  requested  an  output  of  an 
already  fully  completed  form  (Menu  Selection  Sequences  3.2,  3.3,  3.4, 
and  3.5).  For  these  outputs  there  is  no  corresponding  DS 22  data  and 
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therefore  the  data  elements  from  the  DS22  data  are  blank.  The  data  for 
the  012  outputs  of  fully  completed  forms  is  derived  from  the  DS14  data 
for  that  form  by  specifying  the  completed  forms  identifier  (ID18)  for 
the  form  which  the  user  wishes  to  generate.  For  Missing  Data  Element 
Type  Forms  (i.e.,  forms  generated  by  the  program  to  collect  data  missing 
from  the  OHMIS  data  base)  it  is  not  possible  to  regenerate  the  012 
output  once  the  form  has  been  completed,  because  the  contents  of  the 
form  are  not  maintained;  once  entered,  the  missing  data  is  stored  in  the 
location  where  the  data  element  types  would  have  been  stored  had  the 
data  not  been  missing  and  the  format  and  contents  of  the  Missing  Data 
Element  Type  Form  (which  was  stored  on  the  DS22  data)  is  deleted. 

When  generating  an  012  output,  the  user  may  specify  that  he/she  wishes: 

o  A  particular  previously  generated  form,  by  providing  the 
completed  form  identifier  (ID18)  for  that  form; 

o  a  particular  version  of  a  form  type,  by  providing  the  forms 
specification  identifier  (ID16)  for  that  version  of  the  form; 

o  the  default  version  of  a  particular  form  type  by  providing  the 
form  type  code  (CT9)  for  the  type  of  form  desired; 

the  applicable  version  of  a  form  of  a  given  type,  by 
providing  the  values  for  the  factors  that  determine  which 
version  of  that  form  type  is  applicable. 
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TITLE:  OHM I S  'Blank1  Form  (Generic) 


1.  Title  of  this  type  of  form.  Obtained  from  the  OHMIS  vocabulary 
word/phrase  list  for  the  form  type  code  (CT9)  for  this  type  of 
form. 

2.  Supplemental  title  for  this  version  of  the  form,  if  any.  From 
the  0S10  data. 

3.  General  instructions  for  the  use  of  the  form.  From  the  OS  10 
data. 

4.  Statement  indicating  whether  or  not  this  is  a  Missing  Data  Element 
Type  Form,  i.e.,  a  form  generated  by  the  OHMIS  program  to  collect 
information  that  is  missing  on  a  given  identifier  (e.g.,  employee, 
facility,  etc.). 

Identification  Data 

5.  Form  type  code  (CT9) .  There  will  be  a  standard  form  type  code 

for  Missing  Data  Element  Type  Forms;  otherwise  this  is  specified  by 
the  user. 

6.  Forms  specification  identifier  (ID16)  for  this  version  of  the 
form.  There  is  no  ID15  for  Missing  Data  Element  Type  Forms.  For 
other  forms  the  ID16  is  either  specified  by  the  user  or  is 
determined  by  the  program  during  Function  F3A  based  on  the  type  of 
form  (CT9)  and  the  match  between  the  forms  applicability  values 
data  (0S13)  and  the  values  given  by  the  user. 

7.  Completed  form  identifier  (ID18).  This  is  a  unique  value 
assigned  by  the  program  to  each  new  output  of  an  OHMIS  form.  It 
distinguishes  one  set  of  completed  forms  data  (DS14)  entered  on  an 
OHMIS  form  from  all  other  sets  of  data  entered  on  the  same  type  and 
version  of  the  form.  If  the  user  is  requesting  an  012  output  for  a 
previously  generated  form,  he/she  specifies  the  ID18  to  identify 
the  form  desired. 

8.  Date  this  form  generated.  Identified  by  the  OHMIS  Function  F3A 
program  at  the  first  time  that  the  form  is  generated.  From  the 
DS22  data  for  previously  generated  forms. 

9.  T ime  from  the  above  date  that  this  completed  form  is  due  to  the 
person  requesting  the  data  (specified  below).  This  is  calculated 
from  data  given  in  the  OSLO  data  that  corresponds  to  the  above 
ID16,  if  the  DS10  data  specifies  any  time;  otherwise,  it  is 
specified  by  the  user  and  stored  on  the  DS 22  data. 

10.  OHMIS  service  area  identifier  (ID10)  out  of  which  this  form 
specification  was  generated.  From  the  DS10  data  for  first-time 
forms;  from  the  DS22  data  for  previously  generated  forms;  same  as 


1 


OUTPUT  012:  Mock  Ut 


the  1010  on  the  originating  form  for  the  Missing  Data  Element  Type 
Forms  (where  'originating  form*  means  the  form  that  was  being 
generated  by  the  user  which  triggered  the  generation  of  the  Missing 
Oata  Element  Type  Form). 

The  OHMIS  user  identifier  (ID13)  or  0HM1S  position  identifier 


( IDi4)  of  the  person  who  is  supposed  to  complete  this  form.  Maybe 
an  employee  identifier  (ID4),  if  person  is  not  an  OHMIS  user  or 
does  not  fill  and  OHMIS  position.  For  first-time  forms  this  may 
be  specified  by  the  user.  If  it  is  not,  the  program  examines  the 
DS10  data  for  the  type  of  OHMIS  user  (CT1)  or  type  of  OHMIS 
position  (CT2)  for  the  person  who  is  supposed  to  complete  this 
form.  If  the  DS10  data  does  not  specify  a  CT1  or  CT2  code,  this  is 
left  blank.  For  Missing  Data  Element  Type  Forms  the  person  who  is 
supposed  to  complete  the  form  is  the  same  as  the  person  who  is  to 
complete  the  originating  form.  If  the  012  is  generated  only  for 
examination  purposes,  i.e.,  in  Menu  Selection  Sequence  2.1.4  and 
not  for  use  in  entering  data,  this  part  of  the  output  is  left 
blank . 

Employee  identifier  (104)  for  the  above  person  if  known.  From 


the  current  user/position  identity  and  address  data  (DS9). 
Address  for  the  above  person.  From  the  DS9  data. 

OHMIS  user  identifier  (ID13)  or  position  identifier  (ID14)  (or 


employee  identifier  (ID4)  if  there  is  no  OHMIS  user/position)  for 
the  person,  if  any  and  if  known,  who  is  supposed  to  review  ('sign 
off  on')  the  completed  form.  For  first  time  forms  this  is  from  the 
CT1  or  CT2  specified  in  the  DS10  data,  if  any  specified.  The  CT1 
or  CT2  is  converted  into  an  ID13  or  ID14  using  the  OHMIS 
user/position  identifier  by  OHMIS  user/position  type  list  (DL8). 

If  not  specified  on  the  DS10,  this  part  of  the  output  is  left  blank 
unless  the  user  generating  the  form  specified  a  reviewer.  The  user 
generating  the  form  may  also  specify  a  person  other  than  the  person 
specified  on  the  DS10  data.  For  previously  generated  forms,  this 
information  is  from  the  0S22  data.  It  is  left  blank  on  forms 
generated  for  the  purpose  of  examination  only  (Menu  Selection 
Sequence  2.1.4). 

Employee  identifier  (ID4)  for  the  above  person. 

Address  of  the  above  person .  From  the  DS9  data. 

OHMIS  user  identifier  (ID13)  for  the  person  requesting  the  data. 

For  first  time  forms  tnis  information  is  determined  by  the  OHMIS 
program  from  the  identity  of  the  person  logging  on  to  the  OHMIS 
program  to  generate  the  form;  or,  the  user  may  specify  a  different 
requestor.  From  the  DS22  data  for  previously  generated  forms. 

Same  as  the  originating  form  for  Missing  Data  Element  Type  Forms. 
Left  blank  on  forms  generated  for  examination  only. 
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18.  Employee  identifier  (104)  for  the  above  person.  From  DS9  data. 

19.  Address  of  the  above  person  with  a  statement  indicating  that  this 
is  the  address  to  which  the  completed  form  is  to  be  returned. 

20.  Data  element  type  description  and  spaces  for  entering  the  date 
that  the  data  on  the  completed  forms  was  obtained. 

21.  Statement  indicating  how  long  after  the  above  date  the  hard  copy  of 
this  form  is  to  be  maintained.  From  the  DS10  data;  if  'O'  on  the 
DS10  data  no  statement  at  all  is  put  on  the  output.  Left  off  of 
the  output  for  Missing  Data  Element  Type  Forms. 

22.  Data  element  type  description  and  space  for  entering  the  employee 
identifier  (ID4)  for  the  person  who  actually  did  complete  this 
form. 

23.  Data  element  type  description  and  space  for  entering  the  employee 
identifier  (ID4)  for  the  person  who  actually  did  review  ('sign  off 
on’)  the  completed  form,  if  any. 

24.  Data  element  type  description  and  space  for  entering  date  that  the 
form  was  reviewed. 

25.  Up  to  9  form  unit  identifiers  for  this  form,  i.e.,  the  unit 
(e.g.,  an  employee  identifier  (104))  or  set  of  units  for  which  this 
form  provides  data.  These  may  have  already  been  completed  (if 

the  user  provided  this  information  when  generating  the  form)  in 
which  case  both  the  data  element  type  description  and  the  value  for 
the  identif ier( s)  that  were  entered  by  the  user  would  be  printed 
out  on  the  output;  or  they  may  be  left  blank  (i.e.,  the  user  did 
not  know  the  identity  of  the  unit  for  which  this  form  was  to  be 
used  at  the  time  that  the  form  was  generated)  in  which  case  only 
the  data  element  type  description  and  space  for  entering  the  form 
unit  identifiers  would  be  provided  on  the  012  output.  For 
example,  the  form  might  say  'Name  of  Employee:'.  If  no  form  unit 
identifier  information  is  provided  by  the  user  when  generating  the 
form,  then  a  set  of  DS22  data  is  not  generated.  For  previously 
generated  forms,  the  forms  unit  identifier  information  is  obtained 
from  the  DS22  data  for  the  form.  For  Missing  Data  Element  Type 
Forms,  there  is  only  one  form  unit  identifier  and  this  is  the 
identifier  for  the  unit  about  which  the  Missing  Data  Element  Type 
Form  is  providing  for  the  collection  of  missing  information. 

Content  of  Form 

25.  For  Missing  Data  Element  Type  Forms,  the  content  of  the  012  output 
consists  of  a  series  of  up  to  20  data  element  type  descriptions  and 
spaces  for  entering  the  values  for  these  data  element  types.  The 
missing  data  element  types  are  identified  by  the  program  at  the 


OUTPUT  012:  Mock  Up 


time  that  the  originating  form  is  generated  by  the  user.  To  do 
this,  the  program  examines  each  of  the  forms  unit  identifiers 
provided  by  the  user  when  generating  the  form  and  uses  the  missing 
data  element  list  (QL25)  to  determine  if  there  are  any  missing  data 
element  types  for  the  form  unit.  The  missing  data  element  type 
information  identifier(s)  ( ID21 )  for  this  unit  are  entered  onto  the 
DS22  data.  When  printing  the  012  output,  there  are  up  to  20  pairs 
of  the  following  information:  The  data  element  type  description 
and  space  for  entering  the  value  for  the  data  element  type. 

27.  For  other  forms,  the  contents  of  the  form  consists  of  the  data 
element  type  description  and  spaces  for  entering  values  for  the 
data  element  types  in  the  forms  subpart  data  sets  (DS11)  specified 
on  the  DS10  data  corresponding  to  the  forms  specification 
identifier  ( 1016 )  for  the  form.  Specifically,  the  contents  consist 
of  the  following  sets  of  information  for  each  forms  subpart: 

o  The  subtitle  of  the  form  subpart  (if  any). 

o  The  instructions  for  the  form  subpart  (if  any). 

o  The  data  element  type  description  and  space  for  entering  the 

information  for  each  of  the  up  to  6  data  element  types  in  this 
forms  subpart. 

28.  A  statement  asking  the  user  to  identify  those  data  element  types 
which  the  user  wishes  to  have  considered  as  'secondary  base  line 
data1.  As  explained  in  the  DS14  data,  a  secondary  base  line  value 
is  a  value  other  that  the  original  base  line  value  that  the  user 
wishes  to  be  treated  as  though  it  were  the  base  line  value.  This 
statement  is  omitted  from  Missing  Data  Element  Type  Forms  and  forms 
for  which  the  DS10  data  indicates  that  there  are  no  data  element 
types  on  the  form  that  can  have  base  line  entries  for  the  data 
element  type. 


OUTPUT  013:  Description 


Outstanding  Data  Requests  List 


This  output  lists  selected  data  elements  for  the  outstanding 
(uncompleted)  forms  monitoring  data  (DS22)  for  those  OHMIS  forms  that 
have  been  generated  and  sent  for  completion,  but  which  have  not  yet  been 
completed  and  returned  to  OHMIS.  The  purpose  of  the  output  is  to  enable 
the  OHMIS  Data  Processing  Staff  person  to  monitor  what  forms  have  not 
been  received  and  to  send  out  a  new  request  for  the  data,  if  needed. 
Further  information  on  the  type  of  data  requested  can  be  obtained  by 
generating  the  blank  form  (Output  012)  again  (Function  F3A;  asking  for  a 
previously  generated  form)  for  the  completed  form  identifier  (ID18) 
given  on  this  output. 

Generation  of  Output:  Most  of  the  013  data  is  obtained  from  the  DS22 
data.  Some  data  comes  from  the  forms  specification  data  (DS10)  and  the 
name  on  the  013  list  comes  from  the  current  user/position  identity  and 
address  data  (0S9). 

The  output  is  generated  in  two  ways: 

1)  1  Automatical  1 y ‘  (see  Function  F1A):  An  013  list  for  an 
OHMIS  service  area  (ID10)  is  generated  each  day  that  the 
OHMIS  Data  Processing  Staff  for  that  OHMIS  service  area  logs 
on  to  the  OHMIS  system.  The  log  on  program  keeps  track  of  the 
last  date  on  which  the  013  list  was  generated  and  compares  the 
current  date  each  time  a  user  with  a  OHMIS  user  identifier 
(ID13)  that  is  for  an  OHMIS  Data  Processing  Staff  type  of  user 
(CT1)  for  the  OHMIS  service  area  (ID10)  enters  the  system. 

The  automatically  generated  013  includes  a  list  of  only  those 
outstanding  (uncompleted)  forms  that  are  over  due  (as 
determined  from  the  list  of  over  due  data  requests  by  the 
OHMIS  service  area  (DL28))  or  forms  that  do  not  have  a  due 
date  (as  determined  from  the  list  of  outstanding  data  requests 
(no  due  date  specified)  by  OHMIS  service  area  (DL27)). 

2)  Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
3.7.  Requests  may  be  for: 

o  All  over  due  data  requests  for  an  OHMIS  service  area, 
i.e.,  all  OHMIS  forms  that  have  not  been  received  that 
were  due  to  be  received  before  the  current  date.  This 
output  is  generated  using  the  over  due  data  requests  by 
OHMIS  service  area  (DL28). 

o  All  outstanding  data  requests  for  an  OHMIS  service  area, 
i.e.,  all  forms  that  have  not  been  received,  even  those 
that  are  not  yet  due.  This  output  would  be  generated 
using  DL28  and  the  list  of  new  outstanding  data  requests 
(not  over  due)  by  OHMIS  service  area  (DL26);  and,  the 
list  of  outstanding  data  requests  (no  due  date  specified) 
by  OHMIS  service  area  (DL27). 


OUTPUT  013:  Description 


Each  013  list  is  printed  with  all  outstanding  requests  from  a  given 
person  (i.e.,  all  outstanding  forms  that  are  supposed  to  be  completed  by 
a  given  person)  grouped  together  and  in  order  of  due  date  (if  one  was 
given)  for  multiple  forms  due  from  the  same  person.  The  user  can 
specify  a  013  output  for  a  given  person  from  whom  the  data  has  been 
requested.  The  user  can  also  specify  an  013  output  for  all  those 
requests  made  by  a  given  person. 


OUTPUT  013:  Mock  Up 


TITLE:  Outstanding  Data  Requests  Lists 


Instructions  on  how  to  use  this  output. 

Date  this  output  generated. 

OHMIS  service  area  identifier  ( 1010)  for  which  this  output  was 
generated.  This  identifier  can  either  be  specified  by  the  user 
when  requesting  the  generation  of  the  output  (Menu  Selection 
Sequence  3.7).  If  no  OHMIS  service  area  is  specified,  the  program 
generates  the  output  for  the  service  area  to  which  the  OHMIS  user 
identifier  (ID13)  entered  at  the  beginning  of  the  program  sequence 
(when  'logging  on')  belongs,  as  determined  by  the  OHMIS 
user/position  by  service  a> _a  list  (DL6).  For  automatic 
generations  of  the  013  lists  (i.e.,  outputs  generated  when  the 
OHMIS  Data  Processing  Staff  'logs  on'  once  a  day;  Function  F1A), 
the  program  determines  the  OHMIS  service  area  from  the  I D 13  at  the 
beginning  of  the  log  on  sequence. 

Subinstructions  telling  the  user  that  the  following  is  the  forms 
monitoring  data  for:  l)The  forms  that  are  over  due;  2)  the  forms 
that  have  no  due  date;  or,  3)  all  outstanding  forms. 

Seven  columns  of  information  giving  the  following  selected  data 
element  types: 

1)  Completed  form  identifier  (ID18).  This  identifier  is 
obtained  from  the  DL28  (over  due),  DL27  (no  due  date)  or  from 
the  DL26  (new  data  requests),  DL27  and  DL28  lists,  i.e.,  the 
lists  covering  all  outstanding  forms. 

2)  The  form  title  and  supplemental  form  title.  The  form  title 
is  obtained  from  the  OHMIS  vocabulary  word/phrase  that 
corresponds  to  the  form  type  code  (CT9)  that  is  on  the  DS22 
data  that  corresponds  to  the  above  ID18.  The  supplemental 
form  title  (if  any)  is  the  title  of  a  particular  version  of 
the  form.  It  is  given  on  the  DS10  data  that  corresponds  to 
the  forms  specification  identifier  (ID16)  that  is  on  the  DS22 
data  for  the  above  ID18. 

3)  Forms  unit  identifier  (up  to  9).  From  the  DS22  data. 

4)  Date  this  form  generated.  From  the  DS22  data. 

5)  Date  this  form  due.  Calculated  by  adding  the  length  of  time 
to  complete  the  form  before  it  is  over  due  (given  on  the  DS22 
data)  to  the  date  that  the  form  was  generated.  Leave  blank, 
if  no  length  of  time  has  been  specified. 


Person  (employee  identifier  (104),  QHMIS  user  or  OHMIS 
position  identifier  ( 1013/1014 )  and  name)  from  whom  the  data 
is  requested.  From  the  DS22  data. 


Person  (ID4;  ID13  or  1D14;  and 
data,  if  known.  From  the  DS22 


name)  who  requested  this 
data. 


OUTPUT  014:  Description 


Daily  Schedule 


This  output  provides  a  listing  of  the  tasks  that  have  been  scheduled  for 
each  OHMIS  user  (and  some  OHMIS  positions)  in  an  OHMIS  service  area. 

The  purpose  of  the  output  is  to  inform  each  user  who  has  been  scheduled 
for  tasks  of  the  actions  that  have  been  scheduled  for  that  user  on  a 
given  day. 

Generation  of  Output:  Most  of  the  014  data  is  obtained  from  the 
monthly  schedule  data  (DS27)  for  each  OHMIS  user/position  which  contains 
the  date  and  time  that  each  task  has  been  scheduled  for  the  month,  the 
data  describing  the  tasks  on  the  schedule  come  from  the  specific  task 
scheduling  data  (DS24)  corresponding  to  each  of  the  task  identifiers 
(1023)  that  are  on  the  OS27  data.  Other  data  on  the  task  comes  from  the 
task  type  description  data  (DS23)  corresponding  to  the  task  type  code 
(CT3)  on  the  DS24  data  for  the  task. 

The  output  is  generated  in  two  ways: 

1)  ' Automatical  1 y ‘  (see  Function  F1A):  An  014  is  generated  for 
each  OhMIS  user  (ID13)  and  each  OHMIS  position  ( I D 14 )  in  an 
OHMIS  service  area  ( I  DIO )  for  which  there  is  current  regular 
weekly  schedule  availability  data  (DS26).  This  output  is 
generated  once  each  day  that  the  OHMIS  Data  Processing  Staff 
for  the  OHMIS  service  area  logs  on  to  the  OHMIS  system. 

The  automatic  014  output  consists  of  a  separate  Daily 
Schedule  for  each  user/position  in  the  OHMIS  service  area  for 
the  day  that  the  output  is  generated,  based  on  the  monthly 
schedule  data  (DS27)  covering  that  user/position  and  that  day. 
It  is  envisioned  that  the  OHMIS  Data  Processing  Staff  for  an 
OHM  I S  service  area  will  generate  the  Daily  Schedule  early  in 
the  day  and  distribute  it  to  each  OHMIS  user/position  for  use 
during  the  day. 

2)  Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
7.3.4.  Requests  may  be  for: 

o  Daily  Schedule  for  a  given  date  for  all  user/positions. 
The  scheduling  program  keeps  old  schedules  for  one  week 
after  the  end  of  the  month  covered  by  the  monthly 
schedule  data  (DS27).  There  will  be  in  existence  at  all 
times  monthly  schedule  data  (DS27)  for  at  least  one  month 
in  advance  of  the  current  date,  as  once  a  month  the  OHMIS 
program  (Function  F1A)  generates  a  monthly  schedule  for 
two  months  in  advance  for  all  OHMIS  user/positions  for 
which  there  is  regular  weekly  schedule  data  (DS26). 

There  may  also  be  schedules  for  many  additional  months  in 
advance,  if  the  user  has  provided  scheduling  information 
for  them.  The  user  may  request  an  014  for  any  date  and 


OUTPUT  014:  Description 


the  program  will  check  the  DS27  to  determine  if  the 
scheduling  data  currently  exists  and  inform  the  user,  if 
not. 

o  Daily  Schedule  for  a  given  OHMIS  user  or  position 

(IQ13/ID14)  for  a  given  date.  The  OHMIS  program  will 
check  the  list  of  monthly  schedule  identifiers  by  OHMIS 
service  area  (DL33)  to  determine  if  there  is  a  schedule 
for  the  user/position  specified  and  inform  the  user 
requesting  the  Daily  Schedule. 

The  monthly  schedule  data  (DS27)  from  which  output  014  comes  provides 
scheduling  data  on  an  individual  OHMIS  user/position  for  an  entire 
month.  The  DS27  data  includes  both  information  on  the  time  that  the 
user  has  available  for  scheduling  and  the  actual  task  that  have  been 
scheduled  to  fill  this  time  (if  any).  The  output  014  is  for  only  one 
date  on  the  DS27  data  and  lists  the  information  about  each  time  slot 
(each  quarter  of  an  hour  period)  in  that  day  which  has  been  identified 
as  being  available  for  scheduling.  That  is,  the  output  does  give  an 
indication  of  unscheduled  time  periods  as  well  as  scheduled  time 
periods . 

Unless  otherwise  indicated,  each  data  element  on  the  following  mock  up 
for  014  is  from  th*  DS27  data  for  the  user/position  and  covering  the 
date  of  interest. 


OUTPUT  014:  Mock  Up 
TITLE :  Dai ly  Schedule 


1.  Instructions  on  how  to  use  this  output. 

2.  Date  this  output  was  generated. 

3.  Date  for  which  this  output  is  a  Daily  Schedule. 

4.  OHM  IS  service  area  identifier  ( I  DIO )  for  which  the  output  was 
generated . 

5 .  OHMIS  user  identifier  (ID13)  or  OHMIS  position  identifier  (ID14) 
for  the  user/position  for  which  this  output  constitutes  a  Daily 
Schedule. 

6.  Name  and  ' address'  (for  distribution)  of  the  above  person.  From 
the  current  user/position  identity  and  address  data  (DS9) 
corresponding  to  the  above  ID13/ID14. 

7.  Beginning  with  the  earliest  time  slot  (hour  and  quarter  hour  in  the 
day)  for  which  the  DS27  data  indicates  that  the  user/position  has 
hours  available  for  scheduling,  provide  the  following  two  columns 
of  data: 

1)  The  hour  of  the  day  (I  through  24). 

2)  The  quarter  of  an  hour  time  slot  for  the  above  hour  (1  through 
4). 

Adjacent  to  these  two  columns  of  data  provide  the  following 
additional  ten  columns  of  data  for  each  time  slot  available  for 
scheduling  whenever  the  data  is  different  for  the  same  type  of  data 
for  the  previous  time  slot.  For  example,  if  the  user's  preferred 
time  use  code  was  the  same  for  the  first  twelve  time  slots  (the 
first  three  hours)  it  would  only  be  listed  once  on  the  first  time 
slot  and  then  left  blank  until  a  time  slot  was  reachpd  in  which  the 
preferred  time  use  was  different.  (This  listing  of  inTormation 
only  when  it  changes  is  done  to  make  it  easier  to  read  the  Daily 
Schedule  at  a  glance): 

3)  Preferred  time  use  code  (CT1I)  and  meaning  of  code.  Meaning 
of  code  is  from  the  OHMIS  vocabulary  word/phrase  data  base. 

(The  following  data  elements  are  included  on  the  output  only  if  the 
time  slot  has  been  scheduled.) 

4)  Task  identifier  (  ID23)  for  the  task  scheduled  during  this 
time  slot. 


5)  Brief  task  description  of  the  task.  From  the  task  type 
description  data  (DS23)  corresponding  to  the  task  type  code  on 

specific  task  scheduling  data  (DS24)  corresponding  to  the 
1023  listed  above. 

6)  Estimated  number  of  time  slots  (quarter  of  an  hour  periods) 
required  to  complete  this  task.  From  the  DS24  data. 

7)  Date  this  task  was  triggered.  From  the  DS24  data.  This 
information  will  tell  the  user  how  long  the  task  has  been 
outstanding.  If  it  is  an  undated  (no  due  date)  task  or  if 
there  is  a  long  cue  for  scheduling  tasks  in  this  OHMIS  service 
area  it  is  possible  that  the  task  may  have  been  scheduled  for 
a  very  long  time  since  it  was  triggered. 

8)  Date  task  due,  if  any.  This  is  from  the  DS24  data  and 
applies  only  to  dated  tasks. 

9)  Facility  identifier  (ID8)  for  the  main  location  in  which 
this  task  is  to  be  conducted,  if  known.  From  the  DS24  data. 

10)  Requirement  implementation  identifier  (ID9)  for  the 
requirement  (recommendation)  that  triggered  this  task. 

Putting  this  information  on  the  Daily  Schedule  will  make  it 
easier  for  the  user  to  enter  requirement  disposition  data, 
i.e.,  data  indicating  that  the  requirement  has  been  executed 
(Menu  Selection  Sequence  1.5.3;  Function  F2B).  It  will  also 
be  the  case  that  the  completion  of  a  task  on  the  Daily 
Schedule  will  mean  the  execution  of  a  requirement  and  is 
likely  that  the  user  will  wish  to  enter  the  requirement 
disposition  data  on  the  requirement  immediately  following  the 
completion  of  the  task  on  the  Daily  Schedule. 

11)  The  amount  of  time  needed  to  complete  this  task,  if  it  was  not 
possible  to  complete  the  task  during  the  amount  of  time 
scheduled  for  the  task.  This  information  would  be  entered  by 
the  user  onto  the  specific  task  scheduling  data  (DS24)  for  the 
task  so  that  the  OHMIS  rescheduling  program  (Function  F4B) 
could  use  this  information  when  rescheduling  the  task. 

12)  Space  for  the  user  to  write  in  comments  about  the  task,  e.g., 
to  check  if  the  task  has  been  completed,  to  make  notes  on  the 
need  for  rescheduling,  etc. 


OUTPUT  015:  Description 


Schedul inq  Notice 


This  output  is  simply  a  notice  to  the  person  affected  that  they  have 
been  scheduled  to  participate  in  a  given  task.  The  most  frequent  use  of 
this  notice  will  be  to  notify  employees  that  they  have  been  scheduled 
for  routine  medical  examinations,  follow-up  tests,  pre-employment 
physicals,  etc. 

Ueneration  of  Output:  Most  of  the  data  on  this  output  comes  from  the 
specific  task  scheduling  data  (DS24)  for  the  task  for  which  this  output 
constitutes  a  notice.  Some  of  the  data  comes  from  the  facility  data  by 
task  type  data  (DS25)  and  the  task  type  description  data  (DS23) 
corresponding  to  the  task  type  code  (CT8)  given  on  the  OS 24  data. 

This  output  is  generated  in  two  ways: 

1)  ' Automatical  1 y '  (see  Function  F4A):  A  015  Notice  is 
generated  at  the  time  that  the  task  is  scheduled,  if  the  task 
type  description  data  (DS23)  on  the  task  indicates  that  a 
Scheduling  Notice  is  to  be  generated.  The  Scheduling  Notice 
is  sent  to  the  person(s)  identified  (generical ly)  on  the  DS23 
data.  This  output  is  generated  once  when  the  task  is 
scheduled,  each  time  the  task  is  rescheduled  and  once  two 
weeks  before  the  task  is  scheduled. 

2)  Upon  the  request  of  the  user,  using  Menu  Selection  Sequence 
7.3.5.  These  Scheduling  Notices  are  sent  to  the  person 
specified  by  the  user  as  a  part  of  the  request  made  for  the 
Scheduling  Notice. 


j 


I 


OUTPUT  Q15:  Mock  Up 


TITLE:  Scheduling  Notice 


1.  Instructions  (explanation)  about  how  to  use  this  output. 

2.  Date  this  output  was  generated. 

3.  Task  identifier  (ID23)  for  this  task.  Identifies  the  specific 
task  scheduling  data  (DS24)  for  the  task  covered  by  this  Scheduling 
Notice. 

4.  Employee  identifier  (ID4)  of  the  person  to  whom  this  notice  is  to 
be  sent.  The  ID4  is  obtained  in  one  of  the  following  ways: 

o  It  is  provided  by  the  user  at  the  time  that  the  request  for 
the  Scheduling  Notice  is  made  (Menu  Selection  Sequence  7.3.5). 

o  It  is  obtained  from  the  requirement  implementation  data  (DS5) 
for  the  requirement  that  triggered  this  task.  The  DS5  data  is 
referenced  by  the  ID9  given  on  the  DS24  data  corresponding  to 
the  above  ID23.  The  program  uses  the  task  type  description 
data  (DS23),  identified  by  the  task  type  code  (CT8)  on  the 
DS24  data  corresponding  to  the  above  ID23  to  determine 
generically  what  type  of  enployee  is  to  be  notified.  It  then 
uses  the  DS5  data  to  either  identify  the  requirement 
implementation  unit(s)  for  the  task.  Depending  on  the  generic 
person  identified  on  the  DS23  data,  either  the  employee 
identifier  (ID4)  that  is  one  of  the  requirement  implementation 
unit(s)  is  the  person  that  is  to  be  notified;  or,,  the  contact 
and  location  data  vDS28)  corresponding  to  one  of  the 
requirement  implementation  units  identifies  the  person  to  be 
notified. 

5.  1  Address'  data  for  the  above  employee.  From  the  contact  and 
location  data  (DS28)  for  the  employee  or  other  requirement 
implementation  unit  for  the  task. 

6.  Description  of  the  task  used  for  scheduling.  From  the  DS23  data. 

7.  T ime  slot  for  the  task,  i.e.,  the  date,  hour  and  minute  the  task 
is  to  begin.  Also,  the  time  slot  that  the  task  is  scheduled  to 
end.  From  the  DS 24  data. 

8.  Description  and  address  of  the  location  to  which  the  above  person 
is  to  report  for  the  task.  This  includes  the  following  data 
elements  all  of  which  are  obtained  from  the  facility  data  by  task 
type  (0525  )  correspond ing  to  the  task  type  code  (CT8)  and  OHM  I S 
service  area  identifier  (ID10)  on  the  DS24  data  corresponding  to 
the  above  ID23: 


OUTPUT  015:  Mock  Up 


a)  Facility  type  code  (CT7)  and  description  of  the  facility 
type  given  on  the  OHMIS  vocabulary  word/phrase  data  base  for 
this  code.  May  be  left  blank  if  no  such  CT7  was  given  on  the 
DS25  data. 

b)  Generic  description  of  the  facility  to  which  the  employee  is 
to  report,  e.g.,  "to  the  place  where  you  report  for  work"; 
this  description  comes  from  the  DS25  data  and  is  used  if  no 
CT7  is  given  on  the  DS25  data. 

c)  Facility  identifier  (ID8)  for  the  facility.  Left  blank  if 
not  given  on  the  DS25  data. 

d)  Address  of  the  facility,  including  the  specific  room  (if 
applicable)  to  which  the  employee  is  to  report. 

e)  Additional  information  about  the  facility,  if  any,  e.g., 
directions,  passes  needed,  etc. 

9.  Special  instructions  to  the  employee  on  how  to  prepare  for  this 
task,  e.g.,  not  to  eat  breakfast  that  day,  etc.  From  the  DS23  data 
and/or  DS24  data. 

10.  Requests  from  the  employee  receiving  this  015  output  to  verify 
receipt  and  confirm  the  acceptability  of  the  scheduling  time.  This 
could  be  a  tear  off  portion  of  the  Scheduling  Notice  or  a  second 
page  of  the  Scheduling  Notice  or  it  could  be  printed  on  NCR  type 
paper  or  some  other  method  of  providing  a  return  of  the  Notice  from 
the  employee  receiving  it.  The  person  receiving  the  Scheduling 
Notice  would  indicate: 

o  Whether  or  not  he/she  is  able  to  meet  the  schedule  given 
above; 

o  if  not,  preferred  date  and  time;  and, 

o  any  explanation  of  scheduling  restrictions,  i.e. 

information  about  other  times  that  the  employee  will  not  be 
able  to  participate  in  the  task. 

This  portion  of  the  Scheduling  Notice  will  be  returned  to  the  OHMIS 
Data  Processing  Staff  person  for  use  in  rescheduling  the  task  in 
which  the  employee  will  participate,  if  necessary.  The  information 
on  restrictions  provided  on  the  Notice,  if  any,  will  be  added  to 
either  the  spec i al  restrictions  data  on  the  DS24  data  or  to  the 
standard  restrictions  on  the  DS28  (and  corresponding  DS26)  data, 
depending  whether  the  employee  indicates  that  the  restriction  is  an 
ongoing  one  (e.g.,  works  swing  shift),  i.e.,  a  standard 
restriction;  or,  a  one-time  one  (e.g.,  annual  leave  time),  i.e.,  a 
special  restriction. 


Scheduled/Not  Scheduled  Task  Description 


This  output  is  used  to  provide  the  OHMIS  user/position  with  a  detailed 
description  of  a  task  that  has  been  scheduled  to  enable  the  user  to  more 
easily  determine  what  is  involved  in  executing  the  task.  It  is  expected 
that  the  user  ■•ill  note  that  a  task  is  scheduled  on  the  Daily  Schedule 
(output  014)  and  then  refer  to  the  016  output  for  the  details  about  the 
task. 

Generation  of  Output:  Unless  otherwise  specified,  the  data  on  this 
output  comes  from  the  specific  task  scheduling  data  (DS24)  for  the  task 
which  is  covered  by  this  output.  Some  of  the  data  comes  from  the  task 
type  description  data  (0S23)  corresponding  to  the  type  of  task  for  which 
this  output  was  generated  as  determined  by  the  task  type  code  (CT8)  on 
the  DS24  data.  One  set  of  data  elements  comes  from  the  monthly  schedule 
data  set(s)  (DS27)  on  which  this  task  is  scheduled.  Also,  the  list  of 
qualified  employee  identifiers  (ID4)  by  task  type  (CT8)  and  by  OHMIS 
service  area  (DL34)  is  used. 

This  output  is  generated  in  two  ways: 

1)  1  Automatical  1 y '  (see  Function  FI A ) :  The  016  is  generated 
once  each  day  that  an  OHMIS  Data  Processing  Staff  person  for 
the  OHMIS  service  area  logs  on  to  the  OHMIS  system,  for  each 
of  those  tasks  that  are  listed  on  the  Daily  Schedule  (014) 
generated  at  that  time,  i.e.,  for  that  day.  The 
identification  of  these  tasks  is  obtained  from  the  monthly 
schedule  data  (DS27)  for  the  OHMIS  service  area. 

2)  Upon  the  request  of  the  user  using  Menu  Selection  Sequence 
7.4.3.  The  user  requests  the  016  for  a  given  task  identifier 
( ID23 ) . 


OUTPUT  016:  Mock  Up 


TITLE:  Scheduled/Not  Scheduled  Task  Description 


1.  Instructions  on  how  to  use  this  output,  including  a  statement  on 
whether  this  016  is:  1)  The  first  Scheduling  Notice  for  the  task; 
2)  a  Notice  that  was  generated  as  a  result  of  rescheduling  the 
task;  or  3)  the  'automatic'  resending  of  the  Notice  that  is  done 
two  weeks  prior  to  the  date  that  the  task  is  scheduled. 

2.  Date  this  output  was  generated. 

3.  Task  identifier  (ID23)  for  the  task  being  described  in  this 
output. 

4.  OHMIS  service  area  identifier  ( I  DIO )  for  the  area  in  which  this 
task  originates. 

5.  Task  type  code  (CT8)  for  this  task. 

6.  Detailed  description  of  the  task.  From  the  DS23  data. 

7.  Supplement  to  the  detailed  description  of  the  task. 

8.  Time  use  code  (CT11)  for  the  task. 

9.  Requirement  implementation  unit  identifier! s)  for  the  task. 

11.  Date  task  was  triggered,  i.e.,  date  DS24  data  for  this  task  was 

generated . 

12.  Date  this  task  is  due,  for  dated  tasks. 

13.  Whether  or  not  it  was  possible  to  schedule  this  task  and  if  not 
why,  i.e.,  the  code  'A'  through  1 D*  for  why  not.  (Some  of  the 
following  data  elements  will  be  left  blank  if  the  answer  was  'no'.) 

14.  T ime  slot  (date  and  hour)  this  task  is  scheduled  to  begin.  Also 
the  monthly  schedule  identifier  (ID27)  for  the  monthly  schedule 
data  (DS27)  on  which  this  task  is  scheduled  to  begin. 

15.  Estimated  number  of  time  slots  (quarter  of  an  hour  periods) 

required  to  perform  this  task.  This  is  equal  to  the  user  specified 

number  of  time  slots  required  to  perform  the  task  plus  the  number 
of  interruptions  in  the  scheduling  of  the  task.  This  is  listed  on 
the  DS°4  data  as  the  actual  number  of  time  slots  required  for 
scheduling  the  task. 

Time  slot  (date  and  hour)  at  which  this  task  is  scheduled  to  be 
completed.  Also  ID27. 


16. 


OUTPUT  016:  Mock  Up 


17.  Each  of  the  time  slots  for  which  this  task  is  scheduled.  From 

the  DS27  data.  By  knowing  the  start  time  slot  (from  the  0S24  data) 
each  successive  time  slot  in  which  the  task  is  scheduled  can  be 
determined . 

18.  Whether  or  not  there  are  any  interruptions  in  the  task  as  it  is 
currently  scheduled,  i.e.,  breaks  for  lunch,  other  tasks,  etc. 

19.  Employee  identifier  (ID4)  for  the  primary  person  who  is  to 
perform  this  task. 

20.  OHMIS  user  identifier  (1013)  or  position  identifier  (ID14)  and 
description  of  the  above  person.  From  the  current  user/position 
identity  and  address  data  (DS9). 

21.  Employee  identifier  (ID4),  the  corresponding  user/position 
identifiers  (ID13/ID14)  and  the  monthly  schedule  identifiers  (ID27) 
for  the  start  and  end  time  slots  for  the  up  to  3  other  persons,  if 
any,  who  will  also  be  performing  this  task. 

22.  Description  and  address  of  the  location  in  which  this  task  is  to 
take  place.  This  is  the  same  as  the  information  given  on  the 
Scheduling  Notice  (015).  Canes  from  the  facility  identifier  (ID8) 
given  on  the  DS24  data  and  the  facility  data  by  task  type  (DS25)  if 
there  is  DS25  data  for  this  task  type  (CT8)  and  if  the  ID8  given  on 
this  0S25  data  is  the  same  as  the  IDS  on  the  DS24  data.  Otherwise 
only  the  ID8  is  provided.  May  be  blank,  if  the  location  could  not 
be  determined  as  of  the  date  of  this  output. 

23.  Whether  or  not  this  is  an  ‘employee  transport'  type  of  task. 

24.  Problems  with  scheduling  this  task,  i.e.,  an  indication  of 
whether  it  was  not  possible  to  schedule  this  task  during  the 
preferred  time  use  and  whether  it  was  not  possible  to  schedule  this 
task  to  be  completed  by  the  due  date.  This  information  about  the 
problems  of  scheduling  the  requirement  will  be  used  by  the  users  to 
evaluate  scheduling  problems  and  make  changes  in  the  schedule 
availability  data  in  the  future. 

25 .  Description  of  the  preparation  required  to  perform  this  task. 

From  the  DS23  and  the  0S24  data. 

26.  Requirement  implementation  identifier  (ID9)  for  the  requirement 
implementation  data  (DS5)  that  initiated  this  task. 

27.  Requirement  identifier  (ID6)  for  the  requirement  that  triggered 
this  task.  From  the  DS5  data  for  the  above  referenced  109. 


OUTPUT  016:  Mock  Up 


28.  Brief  description  of  the  requirement  that  triggered  this  task,  if 
any.  From  the  requirement  description  data  (DS1)  for  the  above 
referenced  ID6. 

29.  Whether  this  is  a  Reminder  Notice  (low  priority)  type  task,  i.e., 
whether  this  task  was  triggered  by  Reminder  Notice  type  suspense 
data  (DS4).  If  the  answer  is  Yes,  there  will  be  no  ID6  or  brief 
description  of  the  requirement  given  above. 

30.  Whether  this  task  is  triggered  by  a  mandatory  or  recommended 
requirement.  This  information  would  be  left  blank  if  this  is  a 
Reminder  Notice  type  of  task. 

31.  Description  of  the  qualifications  for  performing  this  task.  From 
the  DS23  data. 

32.  Employee  identifier  (ID4)  and  corresponding  user/position 
identifiers  (ID13/ID14)  for  all  persons  qualified  to  perform  this 
task  in  this  OHMIS  service  area.  From  the  list  of  qualified 
employee  identifiers  by  task  type  and  by  OHMIS  service  area  (DL34). 


OUTPUT  017:  Description 


List  of  Unscheduled  Tasks 


This  output  provides  a  list  of  the  tasks  that  were  triggered  (i.e.,  for 
which  a  set  of  requirements  implementation  data  (DS5)  for  a  requirement 
involving  the  completion  of  the  task  was  generated,  because  this 
requirement  was  found  to  be  applicable),  but  for  which  the  OHMIS 
automatic  scheduling  program  (Function  F4A)  could  not  schedule  a  time 
slot  for  the  task.  As  explained  in  the  specific  task  scheduling  data 
(DS24)  the  only  reason  why  it  would  not  be  possible  to  automatical ly 
schedule  a  task  at  the  time  that  the  task  was  triggered  is  because  there 
were  no  persons  qualified  to  perform  the  task  in  the  OHMIS  service  area 
in  which  the  task  originated  (as  shown  by  the  list  of  qualified  employee 
identifiers  (104)  by  task  type  (CT8)  by  OHMIS  service  area  (DL34))  or 
there  was  no  regular  weekly  schedule  availability  data  (DS26)  on  the 
qualified  persons  in  the  service  area.  This  output  is  used  to  inform 
the  OHMIS  Data  Processing  Staff  person  for  the  OHMIS  service  area  that  a 
task  cannot  be  scheduled  automatically,  so  that  corrections  to  the 
qualified  employee  list  (DL31)  and/or  to  the  schedule  availability  data 
IDS26  or  DS27)  can  be  made. 

Generation  of  Output:  The  data  for  017  comes  primarily  from  the  list 
of  task  identifiers  (ID23)  for  tasks  that  cannot  be  cannot  be  scheduled 
by  OHMIS  service  area  (DL31). 

This  output  is  generated  in  two  ways: 

1)  1  Automatical ly'  (Function  F1A):  A  017  output  is  generated 
for  each  OHMIS  service  area  ( I  DIO )  once  each  day  that  the 
OHMIS  Data  Processing  Staff  person  for  the  service  area  logs 
on  to  the  OHMIS  system.  At  that  time  the  OHMIS  program 
(Function  F1A)  examines  each  task  identifier  on  the  list  of 
task  identifiers  (ID23)  for  tasks  that  cannot  be  scheduled  by 
OHMIS  service  area  (DL31)  and  attempts  to  schedule  them 
(Function  F4A).  If  they  can  be  scheduled,  they  are  removed 
from  the  DS31  list;  otherwise,  they  remain  on  the  list  and  are 
used  in  the  017  output  for  the  day. 

2)  Upon  the  request  of  the  user,  using  Menu  Selection  Sequence 
7.3.7.  The  user  specifies  the  OHMIS  service  area  (ID10)  for 
which  he/she  wishes  a  current  017  output. 


OmiP!£L_01Zi_Jlock_J;^ 


TITLE:  List  of  Unscheduled  Tasks 


1.  Instructions  on  how  to  use  this  output. 

2.  Date  this  output  was  generated. 

3.  OHMIS  service  area  identifier  ( I  DIO )  for  which  this  output  was 
generated. 

4.  Four  columns  of  data  containing  the  following  selected  data 
elements : 

1)  Task  identifier  (ID23)  for  one  of  the  tasks  that  cannot  be 
schedu led. 

2)  Task  type  code  (CT8>  for  the  task.  From  the  DS24  data 
corresponding  to  the  above  1023. 

3)  The  brief  description  of  the  task.  From  the  task  type 
description  data  (0S23)  for  the  task  type  code  (CT8)  given 
above . 

4)  Explanation  of  why  the  task  could  not  be  scheduled.  From  the 
0S24  data. 


6-AO 


TITLES  OF  OHMIS  CURE  DATA  PROCESS' NG  FUNCTIONS 

FUNCTION  FI:  User  Transparent  Functions 

Function  F1A:  'Log-on'  Transparent  Function 

Function  F18:  Triggering  Step  Transparent  Function 

FUNCTION  F2:  Requirements  Functions 

Function  F2A:  Requirements  Check  Function 

Function  F2B:  Function  for  Entering  Requirements  Disposition 
Data 

FUNCTION  F3:  OHMIS  Forms  Data  Processing  Functions 

Function  F3A:  Generation  of  (Blank)  Forms  Functions 

Function  F3B:  Completed  Forms  Data  Entry  and  Allowable  Limits 
Evaluation  Function 

Function  F3C:  Allowable  Limits  Check  Function 

Function  F3D:  Function  for  Canceling  the  Monitoring  of  Outstand¬ 
ing  (uncompleted)  OHMIS  Forms 

FUNCT T 0^'  F4:  Scheduling  Functions 

unction  F4A:  Scheduling  Function 

Function  F4B:  Rescheduling  Function 

Function  F4C:  Function  for  Routine  Generation  of  Tentative 
Monthly  Schedule  Availability  Data 


FUNCTIONAL  DATA  FLOWS 


FOR  ‘FI1  FUNCTIONS:  Transparent  Functions 


This  is  a  series  of  functions  performed  by  the  OHMIS  program  that  is 
transparent  to  the  user.  The  user  executes  a  particular  OHMIS  step 
and  this  results  in  a  data  processing  function  internal  to  the  OHMIS 
program,  i.e.,  a  function  not  performed  at  the  discretion  of  the  user. 
Only  the  less  conventional  transparent  functions  (those  peculiar  to 
the  OHMIS  core  data  processing  program)  are  described  here.  The 
conventional  transparent  functions  such  as  checking  passwords  and 
conducting  edit  checks  of  data  entries  are  not  described  unless  tne 
standard  applications  of  these  conventional  methods  have  been  modified 
for  tne  OHMIS  program. 


1 


FUNCTION  FlA 


‘Log  On1  Transparent  Function 
(Functional  Data  Flow) 


This  functional  data  flow  describes  the  transparent  functions  which 
occur  'automatically1  each  time  that  a  user  logs  on  to  the  OHMIS 
system. 

SUMMARY  OF  SUBFUNCTIONS: 

The  following  are  the  subfunctions  to  be  accomplished  under  this  OHMIS 
function: 

1.  Program  determines  what  access  the  user  has  to  the  OHMIS 
data  base,  including  what  OHMIS  service  area  (1010)  is 
within  the  users  purview  and  which  Menu  Selections  are 
within  the  users  purview. 

2.  The  program  conducts  a  'suspense  check',  i.e.,  looks  for 
all  actions  (requirements  and  reminder  notices)  for  which 
the  suspense  date  has  arrived. 

3.  Program  identifies  all  overdue  data  requests. 

4.  Program  identifies  all  tasks  that  need  to  be  scheduled  or 
rescheduled.  Program  generates  new  'blank'  monthly 
schedule  showing  availability  and  time  use  for  all  time 
slots  for  all  users  in  the  OHMIS  service  area. 

5.  Program  generates  'automatic'  outputs,  i.e.,  outputs 
generated  each  time  a  user  of  a  given  type  logs  on.  These 
automatic  outputs  include: 

a.  Outstanding  Requirements  Checks  Needed  List  (02) 

b.  Outstanding  Requirements  List  (04) 

c.  Reminder  Notice  List  (05) 

d.  Outstanding  Allowable  Limits  Checks  Needed  List  (010) 

e.  Outstanding  Data  Requests  List  (013) 

f.  Daily  Schedule  (014) 

g.  Scheduling  Notices  (015) 

h.  Scheduled  Task  Description  (016) 

i.  List  of  Unscheduled  Tasks  (017) 


TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


STEP  F1A-1 


User  identifies  self  and  provides  password.  Program  checks  password. 


PREVIOUS  STEP:  Each  time  user  ‘logs  on'  to  the  OHMIS  system. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 
R  =  Retrieval) : 

Menu  Selection  and  Input  Sequence: 

SI:  Pre-menus;  log  on  program  sequence 

Ql:  OHMIS  user  identifier  (ID13) 

Q2:  OHMIS  password 

Data  Retrievals: 


DL6:  OHMIS  user/position  identifier  (ID13/ID14)  by  OHMIS  service 
area  (ID10)  list. 

DL7:  OHMIS  user  identifier  (ID13)  by  password  list 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Ask  user  for  Ql  (user  identifier  ( ID13 ) )  and  Q2 

(password).  Determine  if  the  password  (Q2)  is  consistent 
with  the  OHMIS  user  identifier  (ID13)  (Ql).  Yes  *  P2;  No 
=  P6. 

P2:  Retain  (i.e.,  temporarily  store)  the  Ql  throughout  the 

time  that  the  user  remains  logged  on  to  the  system. 

P3:  Match  the  ID13  from  Ql  to  the  OHMIS  service  area 

identifier  (ID10)  using  DL6. 

P4:  Store  the  R3  (current  date)  and  I DIO  from  P3  until  next 

log  on  by  an  OHMIS  user  from  this  OHMIS  service  area 
( ID10) . 

P5:  GO  TO  PI  Step  F1A-2 

P6:  Requery  for  Ql  and  Q2 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F1A-2 


Program  identifies  type  of  OHMIS  user  logging  on;  identifies  data 
access  of  this  type  of  user;  and,  program  determines  whether  'suspense 
check'  has  been  conducted  for  this  day. 

PREVIOUS  STEP:  Step  F1A-2  follows  P5  of  step  F1A-1 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrieval  (R  =  Retrieval): 


Rl: 

The  OHMIS  user  identifier  (ID13)  from  P2  of  Step 
F1A-1 

R2: 

Current  date 

R3: 

Last  date  on  which  an  OHMIS  user  from  the 
service  area  (ID10)  from  P4  in  Step  F1A-1 

OHMIS 

DL6: 

OHMIS  user/position  identifier  (ID13/ID14) 
service  area  (ID10)  list 

by  OHMIS 

DL8: 

OHMIS  user/position  identifier  (ID13/ID14) 
user/position  type  (CT1/CT2)  list 

by  OHMIS 

DL44: 

Menu  Selection  Sequence  by  OHMIS  user  type 

(CT1) 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Match  the  1013  from  Rl  to  the  OHMIS  user  type  code  (CT1) 

using  DL8. 

P2:  Retain  the  CT1  from  PI  throughout  the  time  that  the  user 

remains  logged  on  to  the  OHMIS  system. 

P3:  Identify  the  appropriate  Menu  Selection  Sequence  for  the 

CT1  from  P2,  using  DL44. 

P4:  Match  the  ID13  from  Rl  to  the  OHMIS  service  area 

identifier  (ID10),  using  DL6. 

P5:  Retain  the  ID10  from  P4  throughout  the  time  that  the  user 

remains  logged  on  to  the  OHMIS  system. 

P6:  Is  the  last  log  on  date  (R3)  equal  to  the  current  date 

(R2)?  Yes  =  P 7;  No  =  P8. 

P7 :  GO  TO  P22  of  Step  F1A-3 
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P8:  60  TO  PI  of  Step  F1A-3 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


None 
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This  Step  covers  those  processing  steps  that  should  also  only  be  done 
once  a  day.  The  program  conducts  a  check  for  any  requirements  or 
Reminder  Notices  for  which  the  suspense  date  has  arrived,  i.e., 
conducts  a  suspense  check.  Also  checks  to  determine  whether  there  are 
any  outstanding  data  requests  (i.e.,  OHMIS  forms  that  have  been  sent 
out  for  completion,  but  not  returned)  that  are  over  due.  Also 
determines  if  there  are  any  tasks  that  need  to  be  scheduled  and,  if 
so,  goes  to  Function  F4A. 

PREVIOUS  STEP:  Step  F1A-3  follows  P 8  of  Step  F1A-2 
INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  OHMIS  service  area  identifier  (IDIO)  from  P5  of  Step 

F1A-2 

R2:  Current  date 

R3:  OHMIS  user  type  code  (CT1)  from  P2  of  Step  F1A-2 

R4:  Next  available  requirement  implementation 

identifier(s)  (ID9)  (Note:  All  identifiers  for  data 
sets  are  assigned  in  sequential  number  order  by  the 
program.  The  program  must  keep  track  of  the  last 
identifier  used  for  each  type  of  identifier.) 

R5:  Date  one  week  prior  to  the  current  date,  i.e., 

prior  to  R2 

R6:  Once  a  month  date  on  which  new  DS27  data  is 

generated  (Note:  This  date  will  be  chosen  once  at 
the  initiation  of  OHMIS,  e.g.,  the  first  of  the 
month. ) 

DS1:  Requirement  description  data 

DS4:  Requirements  suspense  data 

0S22:  Outstanding  (uncompleted)  forms  monitoring  data 

DS24:  Specific  task  scheduling  data 

DS26:  Regular  weekly  schedule  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

0S28:  Contact  and  location  data 


j 
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0L3:  Outstanding  requirements  list  by  OHMIS  service  area 

0L9:  Reminder  Notice  list  by  OHMIS  service  area 

Dill:  List  of  active  requirement  application  identifiers 
C IDS )  for  requirements  suspense  data  by  OHMIS 
service  area 

DL26:  List  of  new  outstanding  data  requests  (not  overdue) 
by  OHMIS  service  area 

DL27:  List  of  outstanding  data  requests  (no  due  date 
specified)  by  OHMIS  service  area 

DL28:  List  of  overdue  data  requests  by  OHMIS  service  area 

DL31:  List  of  task  identifiers  for  tasks  that  cannot  be 
scheduled  by  OHMIS  service  area 

DL32:  List  of  the  employee  identifier  (104)  that  is  one  of 
the  requirement  implementation  unit(s)  by  the 
corresponding  requirement  application  identifier 
(105)  and  OHMIS  service  area  identifier  (ID10)  for 
those  ID5s  that  identify  requirement  suspense  data 
sets  (DS4)  that  will  trigger  an  'employee  transport* 
type  of  task 

DL33:  List  of  monthly  schedule  identifiers  (ID27)  by  OHMIS 
service  area  (ID1Q) 

0L35:  List  of  requirement  implementation  identifiers  (109) 
for  requirements  having  tasks  that  need  to  be 
scheduled  by  OHMIS  service  area  (ID10) 

0L39:  List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  by  OHMIS  service  area  (ID10) 

DL4Q:  List  of  weekly  schedule  identifiers  (ID28)  of  OHMIS 
service  area  (ID10)  and  employee  identifier  (ID4) 

DL43:  List  of  weekly  schedule  identifiers  (1028)  by  contact 
identifiers  (ID26)  and  by  OHMIS  service  area  (ID10). 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Identify  the  requirement  application  identifiers  (105)  on 

0L11  that  match  the  ID10  from  Rl. 

P2:  Retain  the  ID5  from  PI  on  a  temporary  list  throughout  Step 

F1A-3,  called  the  P2  list. 
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FNl:  FOR  each  ID5  on  the  P2  list: 

P3:  Identify  the  DS4  data  corresponding  to  ID5;  identify  the 

DS1  data  corresponding  to  the  requirement  identifier 
(106),  if  any,  on  this  DS4  data. 

P4:  Is  the  'next  suspense  date'  field  on  the  DS4  data  equal  to 

or  earlier  than  the  current  date?  Yes  =  P5;  No  =  P12. 

P5:  Generate  a  new  DS5  data  set  based  on  the  DS4  and  DS1  data 

identified  in  P3;  assign  the  next  available  ID9  from  R4. 

Is  the  DS4  data  from  P3  for  a  Reminder  Notice  (i.e.,  not  a 
requirement)?  Yes  =  P6;  No  =  P7. 

P6:  Add  the  109  from  P5,  the  105  from  this  iteration  of  FNl, 

and  the  1010  from  R1  to  DL9;  GO  TO  P8. 

P7:  Add  the  109  from  P5  and  the  ID10  from  Rl  to  DL3. 

P8:  Determine  if  the  DS1  data  from  P3  (or  the  DS4  data,  if 

this  is  a  Reminder  Notice  type  of  suspense  data)  contains 
a  task  type  code  (CT8).  If  yes,  add  the  109  and  ID10  from 
the  DS5  data  generated  in  P5  to  the  DL35  list. 

P9:  Calculate  the  new  'next  suspense  date'  for  the  DS4  data 

from  P3  (using  the  'suspense  interval1);  is  the  new  next 
suspense  date  later  than  the  'last  suspense  date'  on  the 
DS4  data  from  P3?  Yes  =  P10;  No  *  Pll. 

P10:  Deactivate  the  DS4  data,  i.e.,  place  the  current  date  (R2) 

in  the  deactivation  date  for  the  DS4  data  and  remove  the 
ID5  from  0L11.  Delete  the  entry  (if  any)  for  the  105  in 
this  iteration  of  FNl  from  the  DL32  list.  GO  TO  P12. 

Pll:  Replace  old  'next  suspense  date'  on  the  DS4  data  from  P3 

with  the  new  'next  suspense  date'  calculated  in  P9. 

P12:  NEXT  FNl;  end  of  FNl;  GO  TO  P13. 

P13:  Identify  all  of  the  complete  forms  identifiers  (ID18)  on 

DL26  that  match  the  ID10  from  Rl. 

P14:  Retain  the  1018  from  P13  on  a  temporary  list  throughout 

Step  F1A-3  called  the  P14  list. 

FN2:  FOR  each  1018  on  the  P14  list: 

P15:  Identify  the  DS22  data  corresponding  to  the  1018. 

P16:  Does  the  0S22  data  from  P15  specify  a  length  of  time  by 

which  the  outstanding  form  is  due?  Yes  =  P18;  No  -  P17. 

P17:  Remove  the  1018  for  this  execution  of  FN2  from  the  DL26 

list  and  add  it  to  the  DL27  list.  GO  TO  P21. 
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P18:  Add  the  length  of  time  before  the  form  is  over  due 

specified  in  the  DS22  data  from  P15  to  the  date  that  the 
DS22  data  was  generated,  i.e.,  identify  a  date  due. 

P19:  Is  the  date  due  from  P18  equal  to  or  greater  than  the 

current  date  from  R2?  Yes  =  P20;  No  =  P21. 

P20:  Remove  the  ID18  for  this  execution  of  FN2  from  the  DL26 

list  and  add  it  to  the  DL 28  list. 

P21:  Next  FN2;  end  of  FN2,  GO  TO  P25. 

P22:  Is  the  CT1  from  R3  for  an  OHMIS  Data  Processing  Staff  type 

of  user?  Yes  =  P23;  No  =  P24  (Note:  One  or  more  of  the 
OHMIS  user  type  codes  (CT1)  will  be  designated  as  codes 
identifying  OHMIS  Oata  Processing  Staff  type  of  users.) 

P23:  GO  TO  PI  of  Step  F1A-4. 

P24:  GO  TO  P19  of  Step  F1A-5. 

P25:  Review  the  DL33  list  and  obtain  the  monthly  schedule 

identifiers  (ID27)  from  this  "list  for  the  ID10  from  Rl. 

Put  on  a  temporary  list  called  the  P25  list. 

FN3:  FOR  each  1027  on  the  P25  list: 

P26:  Locate  the  0S27  data  corresponding  to  the  ID27  in  this 

iteration  of  FN3. 

P27:  Does  the  DS27  data  from  P26  cover  the  date  from  R5,  i.e., 

is  it  for  the  month  that  includes  the  date  one  week  prior 
to  the  current  date  (R2)?  Yes  =  P28;  No  =  P34 

P28:  Locate  the  filled  fields  covering  the  R5  date  on  the  DS27 

data  from  P26,  i.e.,  locate  the  tasks  scheduled  one  week 
prior  to  this  date.  Place  each  of  the  task  identifiers 
(1023)  that  are  scheduled  on  the  DS27  data  from  P26  for 
the  date  in  R5  onto  a  temporary  list,  called  the  P28  list. 

FN3.1:F0R  each  ID23  on  the  P28  list: 

P29:  Determine  if  there  currently  exists  a  set  of  DS24  data  for 

the  task  with  this  ID23.  Yes  =  P30;  No  (i.e.,  the  task 
has  been  completed)  =  P31 

P30:  Place  the  ID23  from  this  iteration  of  FN3.1  on  a  list 

called  the  P30  list.  Also  erase  all  scheduling 
information  about  this  task  (e.g.,  start  and  stop  time, 
whether  scheduled  in  correct  time  use,  etc.)  from  the  DS24 
data. 

P31 :  NEXT  FN3.1;  end  of  FN3.1,  GO  TO  P32. 
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P32:  Is  the  R5  date  the  last  date  covered  on  the  DS27  data  from 

P26?  Yes  (i.e.,  all  tasks  on  this  DS27  data  have  been  set 
up  to  be  rescheduled)  =  P33;  No  =  P34 

P33:  Erase  the  0S27  data  located  in  P26;  erase  the  1027  for 

this  iteration  of  FN3  from  the  DL33  list. 

P34:  NEXT  FN3;  end  of  FN3,  GO  TO  FN5  (P51). 

P35:  Is  the  current  date  (R2)  the  same  as  the  date  of  the  month 

identified  for  generating  new  DS27  data  (R6 ) ?  Yes  =  P36; 
No  =  P37. 

P36:  Generate  a  flag  indicating  that  it  was  necessary  to  go  to 

the  Function  F4C  subroutine  from  Step  F1A-3  and  the 
program  should  return  to  P37  of  Step  F1A-3  when  Function 
F4C  is  completed.  Retain  this  flag  throughout  the  time 
the  user  is  logged  on  to  the  system  or  until  this  flag  is 
erased  at  the  completion  of  Function  F4C.  GO  TO  PI  of  Step 
F4C-1. 

P37:  Are  there  any  task  identifiers  (1023)  on  the  DL39  list  for 

the  1010  from  Rl,  i.e.,  tasks  that  need  to  be  rescheduled? 
Yes  =  P40;  No  =  P38 

P38:  Are  there  any  task  identifiers  (1023)  on  the  0L31  list  for 

the  I DIO  from  Rl,  i.e.,  tasks  that  could  not  be  scheduled 
previously?  Yes  =  P40;  No  =  P39 

P39:  Are  there  any  requirement  implementation  identifiers  (ID9) 

on  the  DL35  list,  i.e.,  requirements  having  tasks  that 
need  to  be  scheduled?  Yes  =  P40;  No  -  P41 

P40:  GO  TO  PI  of  Step  F4A-1.  When  Function  F4A  is  completed 

the  program  will  return  to  P41  of  Step  F1A-3. 

P41:  Review  the  DL40  list  and  obtain  the  weekly  schedule 

identifiers  (1028)  from  this  list  for  the  ID10  from  Rl. 

Put  these  1028s  on  a  temporary  list  called  the  P41  list. 

FN4:  FOR  each  I 028  on  the  P41  list: 

P42:  Locate  the  DS26  data  corresponding  to  the  ID28  in  this 

iteration  of  FN4. 

P43:  Identify  the  deactivation  date  on  the  DS26  data  located  in 

P42.  Is  this  date  equal  to  or  later  than  the  R2  data 
(current  date)?  Yes  =  P44;  No  =  P50  (next  FN4) 

P44:  Erase  the  DS26  data  located  in  P42. 


P45:  Erase  the  1028  for  this  iteration  of  FN4  from  the  DL40 

list. 
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P46:  Review  the  DL43  list  and  identify  all  entries  (1026s)  for 

the  1028  for  this  iteration  of  FN4  on  this  list.  Put 
these  1026s  on  a  temporary  list  called  the  P46  list. 

Erase  the  entries  from  the  DL43  list. 

FN4.1:  FOR  each  of  the  contact  identifiers  (ID26)  on  the  P46 
list: 

P47:  Locate  the  DS28  data  corresponding  to  the  ID26  for  this 

iteration  of  FN4.1. 

P48:  Erase  the  1026  for  this  iteration  of  FN4.1  from  the  DS28 

data  located  in  P47. 

P49:  NEXT  FN4.1;  end  of  FN4.1,  GO  TO  P50. 

P50:  NEXT  FN4;  end  of  FN4,  GO  TO  P22. 

FN5  (from  P34):  FOR  each  task  identifier  (ID23  on  the  P30  list: 

P51:  Add  the  1023  for  this  iteration  of  FN5  and  the  ID10  from 

Rl  to  the  DL39  list. 

P52:  Locate  the  DS24  data  corresponding  to  the  ID23  for  this 

iteration  of  FN5. 

P53:  Using  the  DS24  data  from  P52,  identify  the  time  slot 

information  for  the  start  time  of  the  task  in  this 
iterationof  FN5. 

P54:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (ID27)  that  is  part  (1)  of  the  time  slot 
information  located  in  P53. 

P55:  Change  the  answer  on  the  DS24  data  from  P3  as  to  whether 

this  task  is  scheduled  to  be  a  'No'  and  enter  the  code  ' C1 
(task  must  be  rescheduled)  as  an  explanation  for  why  the 
task  is  not  scheduled.  Also  erase  all  scheduling 
information  from  this  DS24  data,  i.e.,  the  information 
about  the  scheduling  of  the  task  as  it  was  previously 
scheduled  (e.g.,  start  and  end  time  slot  information, 
whether  the  task  was  scheduled  before  the  due  date,  number 
of  interruptions,  etc.).  Do  not  erase  the  information 
about  whether  more  than  one  person  will  perform  this  task. 

FN5.1:  FOR  each  time  slot  in  which  the  task  for  this  iteration 
of  FN5  was  previously  scheduled  beginning  with  the  start 
time  slot  identified  in  P53  and  the  DS27  data  located  in 
P54  and  continuing  with  the  time  slot  identified  in  P58: 


P56 : 


Locate  the  time  slot  for  this  iteration  of  FN5.1. 
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P57:  Determine  whether  the  scheduling  of  the  task  continues. 

(This  is  shown  on  the  DS27  data  for  the  time  slot  in  this 
iteration  of  FN5.1  as  located  in  P56.)  Yes  =  P58;  No  = 

P61 

P58:  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  continues.  (From  the  DS27  data  for  the  P56  time 
slot. ) 

P59:  Erase  all  of  the  scheduling  information  for  the  task  in 

this  iteration  of  FN5  from  the  DS27  time  slot  located  in 
P56. 

P6Q:  NEXT  FN5.1.  (End  of  FN5.1  will  not  be  reached.) 

P61:  Using  the  DS24  data  from  P52,  determine  if  there  lore 

than  one  person  scheduled  to  perform  this  task.  s  = 

P62;  No  =  P35 

P 62:  Identify  the  up  to  3  monthly  schedule  identifier  P27) 

on  the  DS24  data  located  in  P52  that  specify  the  ly 

schedule  data  (DS27)  on  which  the  scheduling  for  .  task 
for  the  additional  persons  scheduled  to  perform  the  task 
is  shown  to  start.  Put  the  starting  DS27s  on  a 
temporary  list,  called  the  P62  list. 


FN5.2:  FOR  each  1027  on  the  P62  list: 

P63:  Locate  the  DS27  data  corresponding  to  the  ID27  for  this 

iteration  of  FN5.2. 

FN5.2.1:  FOR  each  time  slot  in  which  the  task  in  this  iteration 
of  FN5  is  already  scheduled  and  is,  therefore,  also 
scheduled  for  an  additional  person  to  perform  the  task  at 
the  same  time,  beginning  with  the  date  of  the  month  and 
the  time  slot  number  that  are  parts  (2)  and  (3)  of  the 
start  time  slot  identified  in  P53  on  the  DS27  data  located 
in  P63  and  continuing  with  the  time  slot  identified  in 
P66. 

P64:  Locate  the  time  slot  for  this  iteration  of  FN5.2.1. 

P6b:  Determine  wnether  the  scheduling  of  the  task  continues  to 

another  time  slot.  (This  information  is  shown  on  the  DS27 
data  for  the  time  slot  for  this  iteration  of  FN5.2.1  as 
located  in  P64.)  Yes  =  P66;  No  =  P 69  (next  FN5.2) 

P66:  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  will  continue.  (From  the  DS 27  data  for  the  P64 
time  slot.) 
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P67:  Erase  all  of  the  scheduling  information  for  the  task  in 

this  iteration  of  FN5  from  the  DS27  data  time  slot  located 
in  P64. 

P68:  NEXT  FN5.2.1.  (End  of  FN5.2.1  will  not  be  reached.) 

P69:  NEXT  FN5.2;  end  of  FN5.2,  GO  TO  P70. 

P 70 :  Change  the  answer  to  the  question  on  the  DS24  data  located 

in  P52  about  whether  there  are  additional  persons 
scheduled  to  perform  this  task  to  be  'No'.  Erase  the 
information  about  the  additional  persons  previously 
scheduled  to  perform  this  task  shown  on  the  DS24  data. 

P71 :  GO  TO  P35 . 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS5:  Requirement  implementation  data. 
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Program  determines  whether  the  'automatic'  outputs  for  the  user  who 
has  logged  on  have  already  been  generated. 

PREVIOUS  STEP:  Step  F1A-4  follows  P23  of  Step  F1A-3. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Current  date 

R2:  OHMIS  user  type  code  (CT1)  From  P2  of  Step  F1A-2, 

i.e.,  the  code  for  the  OHMIS  Data  Processing  Staff 
type  of  user. 

R3:  OHMIS  service  area  identifier  (ID10)  from  P5  of  step 

FIA-2 

R4:  Last  date  on  which  an  OHMIS  user  of  the  type  identi¬ 

fied  in  R2  (i.e.,  a  Data  Processing  Staff  type  of 
user)  for  the  OHMIS  service  area  identified  in  R3 
logged  on  to  the  system,  i.e.,  date  last  set  of 
'automatic'  outputs  were  generated. 

PROCESSING  (P  =  Process  Substep;  FN  =  Nor  Next  (program  logic 
loop) ) : 


PI: 

Is  the  last  log  on  date  from  an  OHMIS  Data 
Staff  user  (R4)  equal  to  the  current  date 
No  (i.e.,  current  date  is  later)  =  P3. 

Processing 
(Rl)?  Yes  =  P2; 

P2: 

GO  TO  P19  of  Step  F1A-5 

P3: 

GO  TO  PI  of  Step  F1A-5 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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Generate  'automatic*  output  for  OHMIS  Data  Processing  Staff  user, 
i.e.,  outputs  that  are  generat'd  once  each  day  for  each  OHMIS  service 
area  when  the  OHMIS  Data  Processing  Staff  user  for  the  service  area 
logs  on  to  the  system. 

PREVIOUS  STEP:  Step  F1A-5  follows  P3  of  Step  F1A-4 
INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  OHMIS  service  area  identifier  (IDIO)  from  P5  of  Step 

F1A-2 

R2:  OHMIS  user  type  (CT1)  from  P2  of  Step  F1A-2 

R3:  Current  date 

R4:  Two  weeks  later  than  the  current  date  (R3) 

DSI:  Requirement  description  data 

DS2:  Requirements  check  request  data 

DS5:  Requirements  implementation  data 

DS9:  Current  user/position  identity  and  address  data 

DS23:  Task  description  data 

DS24:  Specific  task  scheduling  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

DL3:  Outstanding  requirements  list  by  OHMIS  service  area 

(IDIO) 

DL9:  Reminder  Notice  list  by  OHMIS  service  area  (IDIO) 

DL12:  List  of  requirement  check  request  identifiers  (ID1) 
by  OHMIS  service  area  (IDIO) 

DL17:  List  of  allowable  limits  check  request  identifiers 
(ID22)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (IDIO) 

0L22:  List  of  active  allowable  limits  application  identi¬ 
fiers  (ID20)  by  forms  specification  identifier  (1D16) 
and  OHMIS  service  area  (IDIO) 
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DL27:  List  of  outstanding  data  requests  (ID18)  (no  due  date 
specified)  by  OHMIS  service  area  (ID10) 

DL28:  List  of  over  due  data  requests  by  OHMIS  service  area 
( ID10) 

DL31:  List  of  task  identifiers  (ID23)  for  tasks  that  cannot 
be  scheduled  by  OHMIS  service  area  (ID10) 

DL33:  List  of  monthly  schedule  identifiers  (1027)  by  OHMIS 
service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
1 oop) )  : 

PI:  Identify  the  requirement  check  request  identifiers  (ID1) 

on  DL12  that  match  the  ID10  from  Rl. 

P2:  Retain  the  IDls  from  PI  on  a  temporary  list  throughout 

Step  F1A-5.  Called  the  P2  list. 

P3:  Print  02  from  101  on  P2  list. 

P4:  Identity  the  requirement  implementation  identifiers  (ID9) 

on  the  DL3  list  that  match  the  ID10  from  Rl. 

P5:  Retain  the  I09s  from  P 4  on  a  temporary  list  throughout 

Step  F1A-5.  Called  the  P5  list. 

FNl:  FOR  each  ID9  on  the  P5  list: 

P6:  Locate  the  DS5  data  corresponding  to  the  ID9. 

P7:  Ooes  the  0S5  data  show  that  the  requirement  has  been 

executed?  Yes  =  P8;  No  =  P10. 

P8:  Retain  the  109  on  a  temporary  list,  called  the  P8  list, 

throughout  Step  F1A-5. 

P9:  GO  TO  Pll. 

P10:  Retain  the  ID9  on  a  temporary  list  throughout  Step  F1A-5, 

called  the  P10  list. 

Pll:  NEXT  FNl;  end  of  FNl,  GO  TO  P12 

P12:  For  each  109  on  the  P8  list,  identify  the  DS5  data 

corresponding  to  the  109  and  identify  the  primary  person 
responsible  for  implementing  the  requirement;  sort  the 
ID9s  on  the  P8  list  in  order  of  this  person;  print  a 
separate  04  for  each  such  person. 
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P13:  For  each  109  on  the  P8  list,  identify  the  DS5  data 

corresponding  to  the  ID9  and  identify  the  person,  if  any, 
who  is  to  supervise  the  execution  of  the  requirement;  sort 
the  ID9s  on  the  P8  list  in  order  of  this  person;  print  a 
separate  04  for  each  such  person. 

P14:  For  each  ID9  on  the  P10  list,  identify  the  DS5  data 

corresponding  to  ID9  and  identify  the  person  who  is  to 
approve  the  disposition  of  the  requirement;  sort  the  ID9s 
in  order  of  this  person;  print  a  separate  04  for  each  such 
person. 

P15:  Identify  the  requirement  implementation  identifiers  (109) 

on  the  DL9  list  that  match  the  ID10  from  Rl. 

PI6:  Retain  the  ID9s  from  P15  on  a  temporary  list  throughout 

Step  F1A-5,  called  the  P16  list. 

P17:  For  each  ID9  on  the  P16  list,  identify  the  DS5  data 

corresponding  to  the  109  and  identify  the  person 
responsible  for  executing  the  action  given  in  the  DS5 
data;  sort  the  ID9s  in  order  of  this  person;  print  a 
separate  05  list  for  each  such  person. 

P18:  GO  TO  P20. 

P19:  End  of  Function  F1A;  present  the  appropriate  type  of  Menu 

'O'  (First  Level  Menu),  as  determined  by  the  CT1  from  R2, 
to  the  user,  GO  TO  the  function  corresponding  to  the 
user's  Menu  Selection  Sequence. 

P20:  Identify  the  allowable  limits  check  request  identifiers 

(1022)  on  0L17  that  match  the  1010  from  Rl. 

P21:  Retain  the  1022  from  P20  on  a  temporary  list  throughout 

Step  F1A-5,  called  the  P21  list.  Print  an  010  from  the 
ID22  on  the  P21  list. 

P22:  Omitted. 

P23:  Identify  the  completed  form  identifiers  (ID18s)  on  the 

DL28  list  that  match  the  1010  on  Rl. 

P24:  Retain  the  ID18s  from  P23  on  a  temporary  list  throughout 

Step  F1A-5,  called  the  P24  list. 

P25:  For  each  ID18  on  the  P24  list,  locate  the  corresponding 

DS22  data. 

P26  -  P27:  Omitted. 


P28:  Sort  the  ID18s  on  the  P24  list  in  order  of  the  employee 

identifier  (104)  of  the  person  who  is  supposed  to  complete 
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the  form.  The  data  on  this  person  is  provided  on  the  DS22 
data. 

P29:  Print  an  013  from  the  ordered  list  of  1018s  generated  in 

P28. 

P30:  Identify  the  completed  form  identifiers  (ID18)  on  the  DL27 

list  that  match  the  ID1Q  on  Rl. 

P31:  Retain  the  1018s  from  P30  on  a  temporary  list  throughout 

Step  F1A-5,  called  the  P31  list. 

P32:  For  each  1018  on  the  P31  list,  locate  the  corresponding 

DS22  data. 

P33:  Sort  the  1018s  on  the  P31  list  in  order  of  the  104  for  the 

person  who  is  supposed  to  complete  the  form. 

P34:  Print  an  013  from  the  ordered  list  of  1018s  generated  in 

P33. 

P35:  Identify  the  monthly  schedule  identifiers  (ID27s)  on  the 

DL33  list  for  the  1010  from  Rl.  Put  on  a  temporary  list 
cal  led  the  P35  list. 

FN2 :  FOR  each  1027  on  the  P35  list: 

P36:  Locate  the  DS27  data  corresponding  to  the  ID27. 

P37:  Does  the  DS27  data  from  P36  cover  the  current  date  (R3), 

i.e.,  is  it  a  monthly  schedule  for  the  month  that  includes 
the  current  date?  Yes  =  P38;  No  =  P41. 

P38:  Locate  the  filled  fields  covering  the  R3  date  (current 

date)  on  the  DS27  data  from  P36,  i.e.,  locate  the  tasks 
scheduled  on  this  0S27  data  for  the  current  date.  Place 
the  task  identifiers  (1023)  for  each  of  these  tasks  on  a 
temporary  list  called  the  P38  list. 

PJ9:  Use  the  1023s  on  the  P38  list  and  the  corresponding  DS24 

data  for  these  tasks  to  print  an  014. 

P40:  Print  an  016  for  each  of  the  ID23s  on  the  P38  list. 

P41:  Does  the  DS27  data  located  in  P36  cover  the  R4  date  (i.e., 

the  date  two  weeks  later  than  the  current  date)?  Yes  = 
P42;  No  =  P47. 


P42:  Locate  the  filled  fields  covering  the  R4  date  (i.e.,  the 

date  two  weeks  from  the  current  date)  on  the  0S27  data 
from  P26,  i.e.,  locate  the  tasks  scheduled  on  this  0S27 
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data  for  the  R4  date.  Place  the  task  identifiers  (ID23) 
for  each  of  these  tasks  on  a  temporary  list  called  the  P42 
1  ist. 

FN2.1:  FOR  each  of  the  ID23s  on  the  P42  list: 

P43:  Locate  the  DS24  data  corresponding  to  this  ID23;  locate 

the  DS23  data  corresponding  to  the  task  type  code  (CT8)  on 
this  DS24  data. 

P44:  Does  the  DS23  data  from  P43  indicate  that  this  is  a  task 

for  which  a  Scheduling  Notice  is  needed?  Yes  =  P45;  No  = 
P46. 


P45 : 

Generate  an  015  for  the  task  with  the  task  identifier 
(ID23)  for  this  iteration  of  FN2.1.  Indicate  in  the 
instructions  given  on  this  015  that  this  is  the  'two 
weeks  previous'  Scheduling  Notice  (015)  for  the  task, 
i.e.,  the  third  type  of  Scheduling  Notice. 

P46: 

NEXT  FN2.1;  end  of  FN2.1,  GO  TO  P47 

P47: 

NEXT  FN2;  end  of  FN2,  GO  TO  P48 

P48: 

Review  the  DL31  list  and  identify  the  task  identifier 
(ID23)  for  those  tasks  from  the  ID10  in  Rl.  Put  on  a 
temporary  list  called  the  P48  list. 

P49: 

Print  an  017  covering  the  ID23s  on  the  P48  list. 

P50: 

GO  TO  P19. 

OUTPUTS  AND 

GENERATION  OF  DATA  SETS: 

02:  Outstanding  Requirements  Checks  Needed  List 

04:  Outstanding  Requirements  List  (three  series;  one  for  each 

person  who  is  to:  execute  requirements,  manage 
(supervise)  requirements,  approve  requirements). 

05:  Reminder  Notice  List  (one  series;  one  List  for  each  person 

who  is  to  execute  the  actions  on  the  Reminder  Notice  List) 

010:  Outstanding  Allowable  Limits  Checks  Needed  Lists 

013:  Outstanding  Data  Requests  Lists  (two  lists;  one  for  over 

due  forms  and  one  for  forms  without  a  due  date) 

014:  Daily  Schedule  (one  series,  i.e.,  one  Daily  Schedule  for 

each  person  who  has  time  available  for  scheduling  on  this 
date,  i.e.,  for  each  person  for  which  there  is  current 
regular  weekly  schedule  availability  data  (DS26)) 


STEP  F1A-5 


015:  Scheduling  Notice  (for  task  requiring  an  015  that  are  due 

two  weeks  from  the  current  date) 

016:  Scheduled/Not  Scheduled  Task  Description  (for  each  of  the 

tasks  that  are  scheduled  today,  i.e.,  the  tasks  that  are 
on  the  series  of  Daily  Schedules  (014)  for  today) 

017:  List  of  Unscheduled  Tasks 
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Triggering  Step  Transparent  Function 
(Functional  Data  Flow) 


This  functional  data  flow  describes  the  data  processing  which  occurs 
each  time  the  user  executes  a  program  sequence  which  has  been 
designated  as  a  'triggering  step'.  In  this  function,  the  information 
triggered  OHMIS  requirements  that  are  potentially  applicable  are 
identified. 

A  triggering  step  is  a  step  in  the  OHMIS  program  logic  (usually  a  data 
entry  step)  which  has  been  designated  as  a  triggering  step.  A  step  is 
designated  as  a  triggering  step  by  the  OHMIS  program  designer.  This 
designation  means  that  the  OHMIS  program  allows  the  user  to  link 
information  triggered  requirements  to  the  execution  of  the 
triggering  step.  That  is,  once  a  step  is  designated  as  a  triggering 
step,  a  check  for  possible  requirements  is  made  each  time  that  that 
triggering  step  is  executed.  For  example,  adding  an  employee  to  the 
Potential  New  Hire  List  (DL2;  07)  may  be  designated  as  a  triggering 
step.  This  would  means  that  the  user  could  specify  that  certain 
requirements  (e.g.,  a  preplacement  physical)  be  triggered  each  time  a 
new  employee  is  added  to  the  DL2  list,  i.e.,  for  each  execution  of 
this  triggering  step. 

Each  time  a  triggering  step  is  executed,  the  program  may  generate 
requirements  check  request  data  (DS2)  as  described  in  this  Functional 
Data  Flow.  Through  this  data,  the  user  is  instructed  to  determine 
whether  any  requirements  are  applicable,  and,  if  so,  generate 
requirements  implementation  data  (DS5),  i.e.,  the  user  is  instructed 
to  conduct  a  requirements  check  (see  Function  F2A).  Alternatively,  if 
there  is  sufficient  data  available  in  the  OHMIS  data  base  at  the  time 
that  the  triggering  step  is  executed,  the  program  will  generate  the 
applicable  requirements  implementation  data  directly  as  a  part  of  this 
Functional  Oata  Flow.  Throughout  the  OHMIS  Functional  Data  Flows,  the 
Steps  that  have  been  designated  as  triggering  steps  will  be  identified 
in  the  'Triggering  Steps  in  this  Function'  section  and  the  types  of 
information  triggered  requirements  that  these  triggering  steps  may 
trigger  will  be  identified  in  the  ’Some  Examples  of  Requirements  to  be 
Triggered  by  this  Triggering  Step1  section. 

SUMMARY  OF  SUBFUNCTIONS:  The  following  are  the  subfunctions  to  be 
accomplished  under  this  OHMIS  function: 

1.  To  identify  all  potentially  applicable  requirements  and, 
if  possible,  determine  whether  they  are  applicable  and 
generate  the  corresponding  requirements  implementation 
data  (0S5)  for  them. 

If  sufficient  information  is  not  available  in  the  OHMIS 
data  base  to  determine  whether  requirements  are  applicable 
at  the  time  that  the  triggering  step  is  executed,  this 
program  will  generate  requirements  check  request  data 
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(0S2).  Through  the  use  of  the  DS2  data,  the  user  will 
provide  the  missing  information  needed  to  determine  if 
requirements  are  applicable. 

TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


STEP  FIB- 1 


Determine  if  there  are  any  information  triggered  applications  of 
requirements  prescribed  by  the  QHMIS  users  as  being  potentially 
triggered  by  the  execution  of  the  triggering  step  for  the  OHMIS 
service  area  to  which  the  user  executing  the  step  belongs. 

PREVIOUS  STEP:  Step  FIB-1  follows  whenever  a  user  executes  a  step 
in  the  UHMIS  program  sequence  that  has  been  designated  as  a  triggering 
step. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  Any  of  the  program  sequences  that  have  been 

designated  as  triggering  steps 

Q/El-5:Requirement  implementation  units.  For  a  given 

triggering  step  there  may  be  up  to  five  data  elements 
entered  as  a  part  of  this  triggering  step  that  are 
designated  as  requirement  implementation  units. 

These  are  the  unit(s)  about  which  the  check  for 
applicable  requirements  triggered  by  the  triggering 
step  is  to  be  conducted.  For  example,  if  the 
triggering  step  is  adding  a  new  employee  to  the 
Potential  New  Hire  List  (DL2;  07),  the  identifier  of 
the  particular  employee  added  in  this  execution  of 
the  triggering  step  would  be  the  value  for  a 
requirement  implementation  unit.  This  particular 
employee  would  be  the  person  about  which  any 
requirements  (i.e.,  those  found  to  be  applicable  as  a 
result  of  the  examinations  of  the  requirements 
triggered  by  this  triggering  step)  would  be 
implemented. 

Date  Retrievals: 

Rl:  Triggering  step  identifier  (ID2)  for  the  triggering 

step,  the  execution  of  which  triggers  this  execution 
of  Function  FIB 

R 2:  OHMIS  service  area  identifier  (ID1U)  retained  in  P5 

of  Step  FlA-2 

DL1U:  List  of  active  requirement  application  identifiers 
(ID5)  for  information  triggered  requirements 
applicability  data  (DS3)  by  triggering  step  (ID2)  and 
by  OHMIS  service  area  (ID10). 


PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 
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PI:  Retain  the  triggering  step  identifier  (ID2)  from  R1 

throughout  Function  FIB. 

P2:  Are  there  any  requirement  application  identifiers  (ID5)  on 

the  OLIO  list  that  match  the  ID2  from  R1  and  the  ID10  from 
R2?  Yes  =  P3;  No  =  P4 

P3:  60  TO  PI  of  Step  FIB-2. 

P4:  End  of  Function  IB;  return  to  the  program  sequence  in 

which  the  triggering  step  was  executed. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  FIB-2 


Identify  the  potentially  applicable  requirements  to  be  triggered  by 
the  execution  of  this  triggering  step. 

PREVIOUS  STEP:  Step  FIB-2  follows  P3  of  Step  F 18-1 . 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Next  available  requirement  check  request  identifier 

(ID1) 

R2:  Q/E  1-5  from  Step  FIB-1 

R3:  The  triggering  step  identifier  (ID2)  retained  in  PI 

of  Step  FIB-1 

R4:  OHMIS  service  area  identifier  (ID10)  retained  in  P5 

of  Step  F1A-2 

R5:  Current  date 

DL10:  List  of  active  requirement  application  identifiers 

(105)  for  information  triggered  requirements 
applicability  data  (DS3)  by  triggering  Step  ID2  and 
by  OHMIS  service  area  (ID10). 


PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) )  : 

PI:  Retain  the  101  from  Rl  throughout  Function  FIB. 

P2:  Generate  a  new  set  of  DS2  data:  Assign  the  ID1  from  Rl, 

the  1010  from  R4,  the  ID2  from  R3,  the  date  from  R5  and 

the  requirement  implementation  units  from  R2. 

P3:  Identify  the  requirement  application  identifiers  (ID5)  on 

the  OLIO  list  that  match  the  ID2  from  R3  and  the  1010  from 

R4. 

P4:  Retain  the  ID5  from  P3  on  a  tenporary  list  throughout 

Function  F18. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


DS2:  Requirements  Check  Request  Data 
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Determine  whether  the  values  of  the  requirement  implementation  units 
entered  as  a  part  of  the  triggering  step  match  the  prescribed  values 
for  these  units  given  for  each  potentially  applicable  requirement  for 
it  to  be  considered  applicable. 

PREVIOUS  STEP:  STEP  F18-3  follows  Step  FIB-2. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  The  temporary  list  of  requirement  application 

identifiers  (ID5)  from  P4  of  Step  F18-2 

R2:  The  requirement  check  request  identifier  (ID1) 

retained  in  PI  of  Step  FIB-2 

R3:  The  DS2  data  (requirement  check  request  data) 

generated  in  PI  of  Step  FIB-2,  i.e.,  the  DS2  data 
with  the  ID1  retrieved  in  R2 

DSl:  Requirement  description  data 

DS3:  (Information  triggered)  requirements  applicability 

data 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 

FNl:  FOR  each  ID5  on  the  Rl  list: 

PI:  Identify  the  0S3  data  corresponding  to  the  ID5. 

P2:  Do  the  values  prescribed  for  requirement  implementation 

units  on  the  DS3  data  from  PI  match  the  values  for  these 
units  on  the  DS2  data  from  R3?  Yes  =  P3;  No  -  P5 

P3:  Retain  the  ID5  on  a  temporary  list  throughout  Function 

FIB. 

P4:  Begin  the  generation  of  a  new  set  of  DS8  data.  Assign  the 

IDl  from  R2;  the  ID5  from  this  iteration  of  FNl;  and  the 
requirements  identifier  (ID6)  from  the  DS3  data  referenced 
in  this  iteration  of  FNl.  Also  assign  spaces  for  the 
values  (not  entered  yet)  for  the  data  element  types  that 
make  up  the  up  to  25  applicability  characteristics  given 
in  the  DS3  data  referenced  in  this  iteration  of  the  FNl 
1  oop. 
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P5 :  NEXT  FNl;  end  of  FNl,  GO  TO  P6. 

P6:  Are  there  any  ID5s  on  the  P3  list?  Yes  =  P7;  No  =  P8 

P7:  GO  TO  Step  FIB-4. 

P8:  Erase  the  DS2  data  from  R3. 

P9:  GO  TO  P4  of  Step  FIB-1. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


DS8:  Values  data  for  requirement  appl icabi 1 i ty  characteristics 


i 
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Determine  if  all  information  needed  to  decide  if  each  potentially 
applicable  requirement  if  in  fact  applicable  is  available.  If  so, 
determine  if  applicable  and,  if  so,  add  new  requirements 
implementation  data  (DS5).  If  not  applicable,  delete  potentially 
applicable  requirements.  If  not  able  to  determine  if  applicable, 
retain  requirement  check  request  data  (DS2)  needed  to  trigger  a 
requirements  check  (Function  F2A)  for  the  user  to  determine  if  the 
requirement  is  applicable.  Otherwise,  delete  the  DS2  data. 

PREVIOUS  STEP:  Step  FIB-4  follows  P7  of  Step  FIB-3. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  The  temporary  list  of  requirement  application 

identifiers  (ID5)  retained  in  P3  of  Step  FIB-3,  i.e., 
the  identifiers  for  potentially  applicable 
requirements 

R2:  The  requirement  check  request  identifier  (IDl) 

retained  in  PI  of  Step  FIB-2 

R3:  The  values  for  any  of  the  data  element  types 

currently  available  in  the  OHMIS  data  base  that 
have  been  designated  as  applicability  characteristics 
data  element  types  in  the  DS3  data  corresponding  to 
the  ID5s  on  the  Rl  list 

R4:  The  next  available  requirement  implementation 

identif ier( s)  (ID9) 

R5:  The  OHMIS  service  area  identifier  (IDlU)  from  P5  of 

Step  F1A-2 

R6:  The  sets  of  values  data  from  requirement 

applicability  characteristics  (DS8)  for  the  RD1  from 
R2,  i.e.,  the  DS8  data  generated  in  Step  FIB-3 

R7:  Requirements  check  request  data  (DS2)  with  the  IDl  in 

R2 

R3:  Next  available  requirement  application  identifier 

(IDS) 

DS1:  Requirement  description  data 

DS3:  (Information  triggered)  requirements  applicability 

data 
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DS9:  Current  user/position  identify  and  address  data 

DS23:  Task  description  data 

013:  Outstanding  requirements  list  (ID9)  by  GHMIS  service 

area  (ID10) 

DLll:  List  of  active  requirement  application  identifiers 
(105)  for  requirement  suspense  data  (DS4)  by  OHMIS 
service  area  (1010) 

0L12:  List  of  requirement  check  request  identifiers  ( 101 ) 
by  OHMIS  service  area  ( I  DIO ) 

DL32:  List  of  the  employee  identifier  (ID4)  that  is  one  of 
the  requirement  implementation  unit(s)  by  the 
corresponding  requirement  application  identifier 
(105)  and  OHMIS  service  area  identifier  ( I DIO )  for 
those  I05s  that  identify  requirement  suspense  data 
sets  (DS4)  that  trigger  an  'employee  transport'  type 
of  task 

DL35:  List  of  requirement  implementation  identifiers  (ID9) 
for  requirements  having  tasks  that  need  to  be 
scheduled  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop)): 

FN1:  FOR  each  105  on  the  R1  list: 

Pi:  Locate  the  DS3  data  corresponding  to  this  105;  the  DS1 

data  corresponding  to  the  requirement  identifier  (106)  on 
this  DS3  data;  and,  the  DS8  data  from  R6  for  this  ID5. 

FNl.l.  FOR  each  of  the  up  to  25  data  element  types  (CT$),  i.e., 

up  to  5  for  each  of  the  up  to  5  requirement  implementation 
units,  identified  on  the  DS3  data  from  PI  as  applicability 
characteristics,  i.e.,  describing  the  characteristics  of 
the  respective  requirement  implementation  unit. 

P2:  Is  the  value  for  the  data  element  type  (i.e.,  one  of  the 

R3s)  currently  available  in  the  OHMIS  data  base?  Yes  = 

P7;  No  =  P3 

P3:  Generate  a  new  DL5  or  identify  the  existing  DL5  with  the 

101  from  RZ  assigned  to  it. 


P4: 


Is  the  data  element  type  for  this  iteration  of  FNl.l 
already  on  the  0L5  list  identified  in  P 3?  Yes  =  P10;  No  = 
P5 
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P5:  Add  the  data  element  type  for  this  iteration  of  FNl.l  to 

the  DL5  list  identified  in  P3. 

P6:  GO  TO  P10. 

P7:  Abstract  the  value  for  the  data  element  type  from  this 

iteration  of  FNl.l  from  the  QHMIS  data  base. 

P8:  Add  the  value  from  P7  to  the  appropriate  field  on  the  DS8 

data  located  in  PI. 

P9:  Does  the  value  for  the  data  element  type  abstracted  in  P7 

match  the  prescribed  value  for  the  dame  data  element  type 
given  on  the  DS3  data  located  in  Pi?  Yes  =  PIO;  No  =  P15 

P10:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  Pll. 

Pll:  Are  there  any  applicability  characteristics  data  element 

types  on  the  DL8  data  identified  in  PI  that  have  missing 
values?  Yes  =  P16;  No  =  P12 

P12:  Is  the  organizational  level  type  code  (CT5)  for  the 

requirement  described  in  the  DS1  data  identified  in  PI  the 
organizational  level  type  code  for  'OHMIS  service  area' 
(i.e.,  the  appl icabil ity  of  this  requirement  is  not  based 
on  a  type  of  organizational  level  other  than  OHMIS  service 
area)?  Yes  (i.e.,  a  requirement  has  been  triggered)  = 

P 13 ;  No  =  P23 

P13:  Does  the  0S1  data  from  PI  (i.e.,  the  DS1  data  for  the 

requirement  that  has  been  triggered)  indicate  that  the 
requirement  that  has  been  triggered  is  a  'Suspense 
Applicability  Data  Generating  Requirement' ?  Yes  =  P14;  No 
=  P18 

P14:  Generate  a  new  set  of  DS4  data,  using  the  DSl  and  DS3  data 

from  PI.  Assign  the  requirement  application  identifier 
(IDS)  from  R8.  Put  the  ID5  assigned  to  the  new  DS4  data 
in  P14  on  the  Dll  list. 

PIS:  Is  there  a  task  type  code  (CT8)  specified  on  the  DSl  data 

from  PI?  Yes  =  P16;  No  =  P22 

P16:  Identify  the  CT8  on  the  DSl  data  from  PI.  Locate  the  DS23 

data  corresponding  to  this  CT8.  Does  the  DS23  data 
specify  that  this  is  an  'employee  transport'  type  of  task? 
Yes  =  P17;  No  =  P22 

P 1 7 :  Put  the  employee  identifier  (ID4)  that  is  one  of  the 

requirement  implementation  unit(s)  from  the  DS4  data  newly 
generated  in  P14  and  the  IDS  and  ID10  for  the  new  DS4  data 
on  the  DL32  list.  GO  TO  P22. 


J 
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P18:  Generate  a  new  set  of  DS5  data,  using  the  DS3  data,  the 

DS1  data  and  the  DS8  data  from  PI  and  the  DS2  data  from 
R7.  Assign  the  109  from  R4,  the  ID1  from  R2,  the  ID5  for 
this  iteration  of  FNl  and  the  I DIO  from  R5.  Fill  in  the 
employee  identifiers  (ID4)  on  the  DS5  data  by  matching  the 
OHMIS  user  identifiers  (ID13)  or  position  identifiers 
(1014)  to  the  employee  identifiers  on  the  DS9  data. 

PI 9 ;  Add  the  ID9  and  the  ID10  assigned  to  the  DS5  data 

generated  in  P18  to  the  DL3  list. 

P20:  Determine  if  the  DS1  data  from  Pi  contains  a  task  type 

code  (CT8) .  Yes  =  P21;  No  =  P22 

P21:  Add  the  ID9  and  the  ID10  assigned  to  the  0S5  data 

generated  in  P18  to  the  DL35  list. 

P22:  Erase  the  DS8  data  located  in  PI. 

P23:  NEXT  FNl ;  end  of  FNl ,  GO  TO  P24. 


P24:  Are  there  any  ranaining  sets  of  DS8  data  with  the  1D1  from 

R2?  Yes  =  P25;  No  =  P26 

P25:  GO  TO  P8  of  Step  FIB-3. 

P26:  Add  the  101  from  R2  to  the  DL12  list. 

P27:  Go  to  P4  of  Step  FIB-1. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS4:  Requirements  Suspense  Data,  i.e.,  date  triggered 

requirements  applicability  data 

DS5:  Requirements  Implementation  Data 

DL5:  List  of  Requirements  Applicability  Characteristics  for 

which  values  are  missing 


i 
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FUNCTIONAL  DATA  FLOWS 

FOR  ' F2‘  FUNCTIONS:  Requirement  Functions 


Requirement  functions  are  those  that  are  involved  in  processing  of 
data  on  OHMIS  requirements.  The  requirement  functions  that  require 
singular  (direct)  data  processing  steps,  i.e.,  the  entry  of  defined 
data  sets  for  the  generation  of  defined  outputs,  are  not  described  in 
the  Functional  Data  Flows  for  this  Function  because  information  about 
direct  inputs  and  outputs  can  be  obtained  from  the  description  of  Data 
Sets  and  Outputs  given  elsewhere.  Only  the  functions  that  involve  a 
series  of  data  processing  steps  (multiple  sets  of  inputs  and  outputs) 
are  described  here. 


I 

I 
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FUNCTION  F2A 


Requirements  Check  Function 


(Functional  Data  Flow) 


This  Functional  Data  Flow  describes  how  the  user  will  execute  a 
'requirements  check',  i.e.,  a  check  to  determine  whether  the 
potentially  applicable  information  triggered  requirements  identified 
in  Function  FIB  are,  in  fact,  applicable. 

A  requirements  check  is  an  exercise  in  which,  for  a  given  set  of 
potential 1y  applicable  information  triggered  requirements ,  the  user 
provides  the  missing  information  needed  to  determine  whether  the 
requirement  is  applicable  and,  if  so,  requirements  implementation  data 
(DS5)  is  generated.  The  information  the  potentially  applicable 
requirements  that  need  to  be  checked  is  given  in  the  requirements 
check  request  data  (DS2)  which  is  generated  by  the  execution  of  the 
triggering  step  (see  Function  FIB  and  Step  F1A-5).  The  user  specifies 
that  s/he  wishes  to  execute  a  requirements  check  using  Menu  Selection 
Sequence  1.2.3. 

SUMMARY  OF  SUBFUNCTIONS: 

The  following  are  the  subfunctions  to  be  performed  under  this  OHMIS 
function. 


1.  Determine  which  of  the  potentially  applicable  requirements 
identified  by  a  requirements  check  request  are  in  fact 
applicable  and,  if  applicable,  generate  requirements 
implementation  data  (DS5). 

TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


STEP  F2A-1 


Identify  the  requirement  check  request  identifier  (ID1)  for  which  this 
requirement  checks  is  being  made.  Enter  the  values  for  the  missing 
applicability  characteristics  (if  any)  that  will  determine  whether  the 
potentially  applicable  requirements  in  this  requirements  check  are  in 
fact  applicable. 

PREVIOUS  STEP:  Step  F2A-1  follows  Menu  Selection  Sequence  1.2.3. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  1  (OHMIS  requirements  data). 

S2:  2  (requirements  check  request  data). 

S3:  3  (conduct  a  requirements  check). 

Ql:  Requirement  check  request  identifier  (ID1). 

El-n:  The  values  for  the  missing  applicability  character¬ 
istics  data  element  types  which  determine  the 
applicability  of  each  of  the  potentially  applicable 
requirements  which  are  being  checked  for  in  the  re¬ 
quirements  check  request  identified  by  the  ID1  from 
Ql.  Up  to  25  data  element  types  for  each  potentially 
applicable  requirement  are  possible.  Data  element 
types  are  listed  on  the  DL5  from  the  ID1  for  Ql. 
Entries  are  requested  in  P5  and  entered  onto  from  1-n 
DS8  data  sets  (depending  on  the  number  of  potentially 
applicable  requirements  for  which  the  data  element  is 
missing  in  P6. 

Data  Retrievals: 

Rl:  Each  of  the  sets  of  values  data  for  requirement 

applicability  characteristics  (DS8)  for  the  ID1  from 
Ql. 

R2:  OHMIS  user  type  (CT1)  from  P2  of  Step  F1A-2. 

R3:  Requirement  check  request  data  (DS2)  for  the  ID1  from 

Ql. 

DL5:  List  of  requirements  applicability  characteristics 

for  which  values  are  missing  for  the  ID1  from  Ql. 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 


STEP  F2A-1 


PI:  Retain  the  ID1  retrieved  in  Q1  throughout  Function  F2A. 

P2:  Is  there  a  015  for  the  101  from  Ql?  Yes  =  P4;  No  =  P3 

P3:  GO  TO  Step  F2A-2. 

P4:  Identify  the  DL5  list  for  the  ID1  from  Ql. 

FNl :  FOR  each  data  element  type  on  the  DL5  list  identified  in 

P4: 

P5:  Request  from  the  user  the  value  for  the  data  element  type, 

i.e.,  request  El-n.  If  the  user  is  not  able  to  provide  a 
value,  GO  TO  P10. 

Pb:  Identify  each  of  the  DS8  data  sets  from  R1  that  are 

missing  the  value  from  the  data  element  type  entered  by 
the  user  in  P5  and  enter  the  value  from  P5  onto  these  DS8 
data  sets. 

P7 :  NEXT  FNl;  end  of  FNl,  GO  TO  P8. 


P8:  Erase  the  DL5  list  identified  in  P4. 

P9:  GO  TO  Step  F2A-2. 

P10:  End  of  Function  F2A;  close  out  and  exit  to  the  appropriate 

menu  'O'  (first  level  menu)  as  determined  by  the  CT1  from 
R2. 


OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F2A-2 


Determine  whether  the  potentially  applicable  requirements  identified 
in  this  requirements  check  are  in  fact  applicable  by  matching  the 
values  for  applicability  characteristics  and  organizational  level  to 
which  the  requirement  is  applicable  against  the  prescribed  values  for 
these  characteristics  and  the  organizational  level.  If  applicable, 
generate  requirements  implementation  data  (DS5). 

PREVIOUS  STEP:  Step  F2A-2  follows  P3  or  P 9  in  Step  F2A-1. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

El:  The  identifier  from  the  organizational  level  to  which 

the  requirement  implementation  units  in  the  DS2  data 
belong.  Request  for  entry  is  executed  in  P6.  Values 
may  be  entered  onto  DS5  data  in  P8. 

Data  Retrievals: 

Rl:  The  requirement  check  request  identifier  (ID1)  from 

PI  of  Step  F2A-1. 

R2:  Each  of  the  sets  of  values  data  for  requirements 

applicability  characteristics  (DS8)  for  the  ID1  from 
Rl. 

R3:  Requirement  check  request  data  (DS2)  for  the  ID1  from 

Rl. 

R4:  Next  available  requirement  implementation  identi- 

fier(s)  (ID9). 

DS3:  (Information  triggered)  requirements  applicability 

data. 

DS9:  Current  user/position  identity  and  address  data. 

DL3:  Outstanding  requirements  list  (ID9)  by  OHMIS  service 

area  (1D10). 

DS12:  List  of  requirements  check  request  identifiers  (1D1) 
by  OHMIS  service  area  (1010). 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 

FNl:  FOR  each  of  the  DS8  data  sets  from  R2. 


STEP  F2A-2 


PI:  Identify  the  DS3  data  corresponding  to  the  requirement 

application  identifier  (ID5)  on  the  DS8  data  and  the  DS1 
data  corresponding  to  the  requirement  identifier  (ID6)  on 
this  0S3  data. 

P2:  Are  all  of  the  applicability  characteristics  values  on  the 

DS8  data  within  the  prescribed  range  of  values  on  the  DS3 
data  from  PI?  Yes  =  F3;  No  =  P10 

P3:  Is  the  type  of  organizational  level  (CT5)  for  which  this 

requirement  applicable  the  OHMIS  service  area  type  of 
organizational  level?  (The  answer  is  given  in  the  DS1 
data  from  PI.)  Yes  =  P8;  No  =  P4 

P4:  Identify  the  type  of  organizational  level  (CT5)  at  which 

the  applicability  of  this  requirement  is  determined  (from 
the  DS1  data  from  PI)  and  tell  the  user  the  type  of 
organizational  level  (CT5)  by  which  the  applicability  of 
this  requirement  is  determined. 

P5:  Print  the  requirement  implementation  units  for  this 

requirements  check  (as  obtained  from  the  DS2  data  from 
R  3 ) . 

P6:  Request  from  the  user  the  identifier  of  the  organizational 

level  (of  the  type  of  organizational  level  (CT5) 
identified  in  P4)  to  which  the  requirement  implementation 
units  printed  in  P5  belong,  i.e.,  execute  El. 

P7:  Does  the  organizational  level  identifier  from  P6  match  the 

range  of  organizational  level  identifiers  prescribed  in 
the  DS3  data  from  Pi?  Yes  (a  requirement  has  been 
triggered)  =  P8;  No  =  P17 

P8:  Does  the  DS1  data  from  PI  (i.e.,  the  DS1  data  for  the 

requirement  that  has  been  triggered)  indicate  that  the 
requirement  that  has  been  triggered  is  a  'Suspense 
Applicability  Data  Generating  Requirement'?  Yes  =  P9;  No 
=  P 13 

P9:  Generate  a  new  set  of  DS4  data  using  the  DS1  and  DS3  data 

from  PI.  Assign  the  requirement  application  identifier 
( IDS)  from  R5. 

Pit):  Put  the  ID5  assigned  to  the  new  DS4  data  in  P9  on  the  DL11 

1  ist. 

PI 1 :  Put  the  requirement  implementation  unit  identifiers  from 
the  DS4  data  newly  generated  in  P9  on  the  DL32  list. 


P12:  GO  TO  P17. 
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P13:  Generate  a  new  set  of  DS5  data,  using  the  DS8  data  from 

this  iteration  of  FN 1 ;  the  DS3  and  the  0S1  data  from  PI; 
and  the  DS2  from  R3.  Assign  the  DS5  data  the  requirement 
implementation  identifier  (ID9)  from  R4;  the  requirement 
application  identifier  (IDS)  from  the  DS8  data  on  this 
iteration  of  FN1;  the  ID1  from  Rl;  and  the  OHMIS  service 
area  identifier  (IDIO)  from  the  DS2  data.  Fill  in  the 
employee  identifiers  (ID4)  on  the  DS5  data  by  matching  the 
OHMIS  user  identifiers  (10113)  or  position  identifier 
(ID14)  to  the  employee  identifier  on  the  DS9  data. 

P14:  Add  the  ID5  and  IDIO  assigned  to  the  DS5  data  generated  in 

P13  to  the  DL3  list. 

P15:  Determine  if  the  0S1  data  from  Pi  contains  a  task  type 

code  (CT8) .  Yes  =  P16;  No  =  P17. 

P16:  Add  the  ID9  and  IDIO  assigned  to  the  DS5  data  generated  in 

P13  to  the  DL35  list. 

P17:  Erase  the  0S8  data  from  this  iteration  of  FNl. 

P18:  NEXT  FN1 ;  end  of  FNl;  GO  TO  P19. 

P19:  Erase  the  OS 2  data  retrieved  from  R3  from  the  OHMIS  files. 

P20:  Delete  the  IDl  retrieved  from  R3  from  the  DL12  list. 

P21:  End  of  Function  F2A,  i.e,  GO  TO  P 10  of  Step  F2A-1. 

OUTPUTS  ANO  GENERATION  OF  DATA  SETS: 

DS4:  Requirement  suspense  data,  i.e.,  data  triggered 

requirements  applicability  data. 


0S5:  Requ irements  implementation  data. 


FUNCTIONAL  DATA  FLOWS 

FOR  ' F3 '  FUNCTIONS:  OHMIS  Forms  Data  Processing  Functions 


These  are  the  set  of  Functional  Data  Flows  that  are  related  to  the 
entry  of  data  onto  OHMIS  forms-  They  include  the  generation  of  a 
blank  OHMIS  form  (012)  of  a  specified  type  and  version,  the  entry  of 
data  from  completed  forms  onto  the  OHMIS  data  base  and  the  evaluation 
of  allowable  limits  specifications  as  they  compare  to  data  entered 
from  OHMIS  forms.  The  OHMIS  program  allows  the  user  to  create  their 
own  forms  (Menu  Selection  Sequence  2.1.1).  This  allows  different 
forms  to  be  generated  for  different  needs  and  for  changes  to  be  made 
easily.  For  example,  a  user  may  wish  to  add  a  particular  piece  of 
information  to  the  pre-employment  physical  when  hiring  an  employee  for 
a  particular  new  job  classification.  The  OHMIS  program  allows  forms 
to  be  changed  or  to  be  different  for  different  OHMIS  service  areas, 
but  still  to  retain  the  same  data  processing  procedures.  It  is 
expected,  however,  that  in  most  cases  the  contents  of  the  forms  will 
be  specified  at  the  DA  level  and  used  throughout  the  OHMIS  system. 

Even  those  differences  in  forms  that  are  required  to  handle  specific 
needs,  for  example,  the  difference  in  forms  between  job  classes,  will 
in  most  cases,  be  handled  by  a  DA-wide  forms  specification.  In 
particular,  it  is  expected  that  the  variation  in  form  content  that  is 
related  to  differences  in  requirements  will  be  specified  at  the  DS 
level.  Individual  OHMIS  service  areas  may  be  allowed  to  add  contents 
to  forms,  but,  in  most  cases,  this  will  be  a  nonrequirement  type  of 
change  to  the  forms  version.  For  example,  the  requirements  of  an 
Industrial  Hygiene  survey  that  are  specified  by  the  contents  of  the 
Industrial  Hygiene  survey  forms  will  in  most  cases  be  specified  at  the 
DA  level.  However,  individual  OHMIS  service  areas  may  wish  to  add 
data  elements  to  the  Industrial  Hygiene  survey  forms  used  locally  to 
meet  particular  needs  or  particular  inquiries.  The  contents  of  OHMIS 
forms  are  specified  in  the  OHMIS  data  base  itself  ( i . e . ,  on  forms 
description  data  ( DS10 ) ) ,  the  control  of  variation  in  forms  content 
can  readily  be  done  centrally. 

The  specific  data  elements  on  each  version  of  each  type  of  OHMIS  form 
are  given  by  the  user  in  Menu  Selection  Sequence  2.1.1  using  the  forms 
specification  data  (DS10).  DS10  data  may  be  entered  at  all  levels 
from  OHMIS  service  area  Data  Processing  Staff  persons  to  the  DA  level. 
If,  for  some  type  of  forms,  the  DA  wishes  only  one  version  of  a  form 
of  a  given  type  to  be  used  without  modification  (e.g.,  without  any 
additions  of  data  elements  at  the  local  level),  this  can  be  specified 
by  stipulating  that  only  the  'default'  version  of  the  form  will  be 
used.  This  stipulation  can  be  made  at  any  time.  The  DA  level  can 
also  specify  that  certain  forms  be  used  by  certain  OHMIS  areas.  These 
stipulations  are  made  using  the  forms  appl icabi 1 i ty  factors  and  values 
data  (DS12  and  DS13).  It  is  envisioned,  however,  that  some  degree  of 
flexibility  at  the  local  level  in  the  type  of  forms  used  will  be 
considered  desirable  in  many  cases.  The  OHMIS  data  base  is  organized 
to  enable  managing  a  data  base  with  different  forms  specifications  for 
the  same  form  type. 


FUNCTIONAL  DATA  FLOWS 


Each  version  of  an  OHMIS  form  has  space  for  entering  the  data  elements 
specified  by  the  user  in  the  specification  for  the  form  and  therefore 
each  form  is  different.  However,  the  format  of  all  forms  is  similar 
in  order  to  enable  standard  processing  of  the  entry  of  data  from  all 
forms.  The  generic  format  of  the  output  of  all  OHMIS  blank  forms  is 
given  in  the  OHMIS  'blank'  form  (generic)  output  (012);  the  generic 
format  for  the  input  of  data  from  OHMIS  forms  is  given  in  the 
completed  forms  data  set  (DS14). 

Section  V  of  this  report  provides  examples  of  some  of  the  major 
types  of  forms  that  will  be  included  in  OHMIS.  The  user  may,  of 
course,  create  an  entirely  new  type  of  form  (based  on  the  data 
element  types  provided  by  the  OHMIS  program  design;  see  DS7).  The 
great  majority  of  form  types  that  will  be  needed  in  OHMIS  will 
probably  be  identified  and  developed  before  the  system  is  initiated. 
Thereafter,  in  most  cases,  the  user  will  be  specifying  only  a 
different  version  of  an  already  existing  form  type. 


I 

i 


I 
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Generation  of  (Blank)  Forms  Function 
(Functional  Data  Flow) 


This  Functional  Data  Flow  describes  how  a  user  generates  a  blank  OHMIS 
form,  i.e.,  an  Output  012,  either  to  examine  the  form  or  to  use  it  to 
enter  data.  (See  description  of  Output  012,  i.e.,  the  OHMIS  blank 
form  (generic)  output.)  These  forms  may  be  hard  copy  forms  on  which 
data  is  entered  manually  in  preparation  for  entry  into  the  computer. 

A1 ternati vely,  tnis  function  may  enable  the  user  to  generate  a  data 
input  'screen'  of  the  data  elements  on  a  particular  form  in  order  to 
input  the  data  directly  without  the  use  of  a  hard  copy  form.  The  same 
'screen'  that  may  be  generated  in  this  Function  is  used  in  Function 
F38  to  provide  a  forms  data  entry  format  for  entering  data  into  the 
computer.  For  the  purposes  of  this  description  of  Function  F3  we  will 
treat  both  hard  copy  and  screen-type  'blank  forms'  as  though  they  were 
both  physical  'outputs'  generated  by  this  function. 

SUMMARY  OF  SUBFUNCTIONS: 

The  following  are  the  subfunctions  to  be  accomplished  under  this  OHMIS 
function: 

1.  Generation  of  a  ‘blank’  form  (012)  meeting  the  user's 
specifications.  This  can  be  the  specific  version  of  a 
form  type  specified  by  the  user,  a  copy  of  3  previously 
generated  form,  or  the  program  can  identify  and  generate 
the  appropriate  blank  form  based  on  matching  the  values 
entered  by  the  user  with  the  forms  applicability  values 
data  (DS13) . 

2.  Generation  of  the  data  needed  to  monitor  each  form  until 
it  is  completed,  i.e.,  generation  of  outstanding 
(uncompleted)  forms  monitoring  data  (DS22).  At  any  point 
in  time  OHMIS  is  able  to  identify  all  forms  for  which 
blank  forms  have  been  generated,  but  for  which  completed 
forms  data  (DS14)  has  not  been  entered,  the  person  who  is 
due  to  complete  each  outstanding  form,  the  date  it  is  due, 
etc.  This  subfunction  is  provided  to  reduce  the  labor 
burden  of  tracking  the  extensive  data  flow  of  the  urtMIS 
system;  it  is  particularly  important  as  many  of  the  forms 
will  be  generated  by  those  outside  of  the  occupational 
health  organization. 

3.  Identification  of  those  data  elements  that  are  missing 
from  the  OHMIS  data  base  for  a  forms  unit(s)  for  which  the 
form  is  being  generated  at  the  time  that  the  form  is 
generated;  and,  the  generation  of  an  additional  form 
(i.e.,  a  Missing  Data  Element  Type  Form)  to  provide  for 
the  entry  of  these  missing  data  elements  by  the  user.  The 
OHMIS  program  is  thus  set  up  to  'automatically'  request 
missing  data  element  types  at  the  same  time  that  other 
data  is  being  requested  tor  the  same  forms  unit  (e.g.,  for 
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the  same  employee).  This  subfunction  is  provided  to 
increase  the  quality  assurance  of  the  OHMIS  data  base  and 
to  reduce  the  labor  that  would  be  required  to  perform  this 
function  if  it  were  to  be  done  manually. 

TRIGGERING  STEPS  IN  THIS  FUNCTION: 

(Note:  As  explained  elsewhere  in  this  report,  a  triggering  step  is  an 
OHMIS  data  processing  step  that  has  been  designated  as  one  that  is  to 
generate  a  check  for  requirements  that  the  user  has  previously 
specified  are  to  be  triggered  by  the  execution  of  this  data  processing 
step  (see  Function  F18,  triggering  step  transparent  function,  for 
further  explanation  of  triggering  steps)).  The  following  are  the 
triggering  steps  that  are  to  be  included  in  this  function: 

On  Step  F3A-3  (P7  and  P 9 )  and  Step  F3A-4  (P18):  Entry  of  data 
to  specify  what  type  and  version  of  a  data  entry  form  is  desired, 
i.e.,  the  point  in  the  OHMIS  program  at  which  the  type  and 
version  of  the  blank  form  being  generated  by  this  function  is 
identified.  It  is  only  a  triggering  step  if  the  form  is  being 
generated  for  use  in  data  entry  (Menu  Selection  Sequence  2.1.5), 
not  if  the  form  is  generated  simply  for  examination  (Menu 
Selection  Sequence  2.1.4). 

Requirement  Implementation  Units  for  This  Triggering  Step 
(As  explained  in  the  requirements  check  request  data  (DS2), 
requirement  implementation  units  are  the  units  about  which 
the  requirements  triggered  by  this  triggering  step  are  to  be 
implemented. ) : 

1.  The  forms  specification  identifier  (ID16)  for  the 
version  of  the  form  generated  by  this  execution  of 
Function  F3A. 


Some  Examples  of  Requirements  to  be  Triggered  by  this 
Triggering  Step:  For  this  triggering  step  the  user  would 
enter  all  requirements  (and  recommendations),  i.e.,  DS1 
data,  that  are  to  be  triggered  by  the  intent  to  collect 
data  of  a  certain  type  (as  shown  by  the  generation  of  a 
specific  version  of  a  particular  type  of  form).  Most  of 
these  requirements  will  depend  on  the  type  of  form  being 
generated,  i.e.,  the  requirements  appl icabi 1 ity  data  (DS3) 
would  specify  a  particular  requirement  for  a  particular  type 
of  form.  For  example,  the  generation  of  a  form  to  conduct 
an  Industrial  Hygiene  survey  would  probably  trigger  differ¬ 
ent  requirements  than  the  generation  of  a  form  to  conduct  a 
medical  examination.  However,  the  following  are  some 
examples  of  types  of  requirements  that  may  be  true  for  most 
types  of  forms  generated: 

1.  Quality  control  procedures.  There  will  in  many 

cases  be  specific  requirements  associated  with  the 
collection  of  a  particular  type  of  data  that  have 
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been  stipulated  by  the  user  to  insure  that  the  quali¬ 
ty  of  the  data  is  maintained. 

2.  Additional  forms  to  be  completed.  It  is  expected 

that  there  will  in  many  cases  be  a  configuration  of 
forms  that  should  be  completed  at  the  same  time.  In 
these  cases,  once  the  user  generates  one  type  of 
form,  there  may  be  a  requirement  notifying  the  user 
of  the  other  forms  that  should  be  generated  and 
completed.  This  type  of  requirement  would  be 
especially  important  for  additional  forms  containing 
data  element  types  that  should  be  updated  frequently. 
For  example,  it  is  recommended  that  an  update  of 
information  on  the  facility! ies)  in  which  an  employee 
works  be  obtained  each  time  the  OHMIS  staff  contacts 
the  employee,  because  of  the  difficulty  of  keeping 
this  type  of  data  current.  One  of  the  signals  for  an 
impending  OHMIS  contact  with  an  employee  is  a 
generation  of  a  blank  form  designed  to  collect 
information  on  an  employee.  Therefore,  it  is 
recommended  that  a  requirement  to  generate  a  form  to 
update  the  information  on  the  employees  work 
facilities  be  triggered  by  triggering  step  3.  The 
requirement  applicability  data  (D$3)  for  this 
requirement  would  specify  that  the  form  specification 
identifier  (1016),  i.e.,  the  requirement 
implementation  unit,  be  for  the  types  and  versions  of 
forms  that  are  generated  to  collect  data  on 
employees,  e.g.,  medical  surveillance  forms. 

Note:  The  above  are  simply  examples  of  the  types  of 
requirements  that  may  be  generated  by  this  triggering  step 
and  how  these  requirements  will  be  specified.  For  any  given 
form  there  would  be  much  more  specific  requirements  (i.e., 
DS3  data  containing  specific  requirements  based  on  specific 
applicabil ity  values. 


STEP  F3A-1 


Determine  and  store  whether  the  user  wishes  to  generate  a  'blank'  form 
to  merely  examine  it  or  to  use  the  form  for  entry  of  data. 

PREVIOUS  STEP:  Step  F3A-1  Follows  Whenever  a  User  Wishes  to  Examine 
or  Generate  a  81ank  OHMIS  Form. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) 

Menu  Selection  and  Input  Sequence: 


SI: 

2 

(forms  spec i f ication  data) 

S2: 

1 

(forms  description  data) 

S3: 

4 

(examine  form  description  data);  OR, 

S3: 

5 

(generate  a  form) 

Data  Retrievals:  None 

PROCESSING  (P  =  Process  substep): 

Pi:  Retain  whether  S3  was  a  '4'  (only  wishes  to  examine  a  form 

specification)  or  a  '5'  (wishes  to  generate  a  form  for  use 
in  data  entry)  throughout  Function  F3A. 

P2:  GO  TO  PI  of  Step  F3A-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F3A-2 


Determine  which  of  the  4  possible  types  of  methods  the  user  wishes  to 
use  to  generate  a  blank  form.  Execute  method  1,  i.e.,  generate  a 
previously  generated  form.  The  previously  generated  form  can  be  a 
blank  form  with  the  identification  information  already  completed  or  it 
can  be  a  Missing  Data  Element  Type  Form. 

PREVIOUS  STEP:  Step  F3A-2  follows  P2  of  Step  F3A-1. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 


Menu  Selection  and  Input  Sequence: 

Ql;  What  method  does  the  user  wish  to  use  to  generate  a 
form.  Answers  may  be: 

1  =  Specify  a  particular  form  that  has  been 

previously  generated 

2  =  Specify  a  particular  version  (specification)  of 

a  form  type 

3  =  Specify  the  default  version  of  a  particular  form 

type 

4  =  Specify  only  the  form  type  and  the  forms 

applicability  values  of  the  form  desired  and 
have  the  program  determine  which  version  of  the 
form  is  appl icable. 

The  query  is  in  Pi. 

Q2:  Completed  form  identifier  (ID18).  Query  is  in  P2. 

Data  Retrievals: 

Rl:  OHMIS  user  type  code  (CT1)  from  P2  of  Step  F1A-2. 

DS9:  Current  user/position  identity  and  address  data 

DS11:  Forms  subpart  data 
DS10:  Forms  description  data 
DS19:  Missing  data  element  information 
DS22:  Outstanding  (uncompleted)  forms  monitoring  data 
PROCESSING  (P  =  Process  substep): 


PI: 


Ask  user  for  answers  to  Ql.  Retain  answers  (1  -  4) 
throughout  Function  F3A.  1  =  P2;  2  =  P 11 ;  3  =  P 11 ;  4  = 
Pll. 


STEP  F3A-2 


P2:  Ask  user  for  answers  to  Q2,  i.e.,  for  the  ID18  of  the 

previously  generated  form.  Retain  this  answer  throughout 
Function  F3A. 

P3:  Locate  the  DS22  data  that  matches  the  ID18  from  P2.  If  no 

match,  tell  user  and  GO  TO  PI. 

P4:  Is  the  DS22  data  from  P3  for  an  Missing  Data  Element  Type 

Form?  Yes  =  P5;  No  =  P7. 

P5:  For  each  of  the  missing  data  element  type  information 

identifiers  (ID21)  on  the  DS22  data  from  P3,  locate  the 
corresponding  DS19  data. 

P6:  Use  the  DS22  data  from  P3  and  the  DS19  data  from  P5  to 

obtain  the  data  needed  to  output  the  desired  form,  i.e., 
output  012.  The  ID18  from  P2  is  the  unique  completed  form 
identifier  for  the  form.  Use  the  standard  title, 
instructions  and  form  type  code  (CT9)  for  all  Missing  Data 
Element  Type  Forms.  The  address  data  on  the  form  is  from 
DS9.  The  data  on  what  data  element  types  are  missing 
(i.e.,  data  element  type  description  and  the  completed 
form  identifier  (ID18),  if  any)  is  from  the  DS19  data 
corresponding  to  the  ID21  on  the  DS22  data.  The  remaining 
data  elements  on  the  blank  form  (012)  are  from  the  DS22 
data.  GO  TO  P10. 

P7:  Locate  the  DS10  data  that  matches  the  forms  specification 

identifier  (ID16)  in  the  DS22  from  P3. 

P8:  Locate  the  sets  of  DS1I  data  that  match  the  forms  subpart 

identif ier(s)  (ID17)  given  in  the  DS10  data  located  in  P7. 

P9:  Using  the  DS22  data  from  P3,  the  DS10  data  from  P7  and  the 

sets  of  DS11  data  from  P8,  obtain  the  data  needed  to 
output  the  desired  form,  i.e..  Output  012.  The  ID18  from 
P2  is  the  unique  completed  form  identifier  for  the  form. 
The  address  data  is  from  DS9.  The  DS22  data  contains  the 
date  the  form  was  generated;  the  date  the  form  is  due;  the 
persons  who  are  to  complete  the  form,  review  the  form,  and 
receive  the  completed  form  (if  these  persons  have  been 
specified);  and,  some  or  all  of  the  forms  unit  data 
element  types  and  values.  The  remaining  data  elements  on 
output  012  are  from  the  DS10  data  and  its  corresponding 
DS11  data. 

PlU:  End  of  Function  F3A;  close  out  all  temporary  files  and 

list  an  exit  to  the  appropriate  Menu  'O'  (First  Level 
Menu)  as  determined  by  the  CT1  from  Rl. 

Pll :  GO  TO  PI  OF  Step  F3A-3. 


STEP  F3A-2 


OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

012:  OHMIS  blank  form  (generic)  of  the  type  specified  by  the 

user. 


STEP  3A-3 


Begin  generation  of  the  data  to  monitor  uncompleted  forms  (DS22). 
Begin  execution  of  methods  2  and  3  (specified  desired  form  version  or 
default  version)  of  the  4  possible  methods  for  generating  a  blank 
form,  by  identifying  the  desired  version  of  the  form. 

PREVIOUS  STEP:  Step  F3A-3  follows  Pll  of  Step  F3A-2. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) 

Menu  Selection  and  Input  Sequence:  Note:  All  E/Q  are  entries 
( ‘ E 1 )  onto  0S22  data  if  R1  is  a  '5'  and  Queries  ( 1 Q ' )  only  if  R1 
is  a  '4' . 

E/Ql:  The  form  type  code  (CT9)  for  the  type  of  blank  form 
the  user  wishes  to  generate.  Entry/Query  is  in  P4. 

E/Q2:  Forms  specification  identifier  (ID16)  for  version  of 
of  blank  form  user  wishes  to  generate.  Entry/Query 
is  in  P8. 

Data  Retrievals: 

Rl:  The  Menu  Selection  Sequence  retained  in  PI  of  Step 

F3A-1,  i.e.,  whether  the  user  wishes  to  generate  a 
form  for  examination  only  ('4')  or  for  use  in 
entering  data  ( ‘5 ' ) . 

R2:  The  next  available  completed  form  identifier  (ID18). 

R3:  Current  date. 

R4:  The  answers  retained  in  PI  of  Step  F3A-2,  i.e.,  the 

type  of  method  (1  -  4)  the  user  chose  to  generate  a 
blank  form. 

R5:  The  OHMIS  service  area  identifier  ( 1010)  retained  in 

P5  of  Step  F1A-2. 

DL21:  List  of  the  active  default  forms  specification 

identifier  ( 1016 )  by  the  form  type  code  (CT9)  and 
OHMIS  service  area  ( I DIO ) . 

DL26:  List  of  new  outstanding  data  requests  (ID18)  (not 
over  due)  by  OHMIS  service  area  (ID10). 

PROCESSING  (P  =  Process  substep): 

PI:  Retain  the  1018  from  R2  throughout  Function  F3A. 

P2:  Is  the  Rl  a  '4'  or  a  '5'?  4  =  P4;  5  =  P3. 


STEP  3A-3 


P3:  Begin  generating  a  new  set  of  DS22  data.  Assign  the  ID18 

from  PI  for  this  DS22  data;  assign  R3  as  the  date  the  DS22 
data  was  generated;  answer  'No'  to  the  question  about 
whether  this  is  an  Missing  Data  Element  Type  Form  on  the 
DS22  data;  assign  the  I DIO  from  R5  to  this  DS22  data;  add 
the  ID18  from  PI  to  the  DL26  list. 

P4:  Ask  for  answers  to  E/Ql,  i.e.,  for  a  form  type  code  (CT9). 

Store  E/Ql  on  the  DS22  from  P3  if  R1  is  a  ' 5 ' .  Also, 
retain  E/Ql  throughout  Function  F3A. 

P5:  Is  R4  a  2,  3,  or  4?  (Could  not  be  a  '1'.)  2  =  P8;  3  = 

P7;  4  =  P6. 

P6:  60  TO  PI  of  Step  F3A-4. 

P 7 :  Use  DL21  to  identify  the  ID16  for  the  default  forms 

specification  for  the  CT9  from  P4  and  the  ID10  in  R5. 
Store/retain  as  in  P4.  (Triggering  Step) 

P9:  Ask  for  answers  to  E/Q2,  i.e.,  the  forms  specification 

identifier  (ID16).  Store/retain  as  in  P4.  (Triggering 
Step) 

P10:  GO  TO  PI  of  Step  F3A-5. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


DS22:  Outstand;ng  (uncompleted)  forms  monitoring  data. 


STEP  F3A-4 


Execute  first  part  of  method  4  for  generating  a  blank  form,  i.e., 
identify  the  applicable  form  based  on  the  applicability  values 
provided  by  the  user. 

PREVIOUS  STEP:  Step  F3A-4  follows  P6  of  Step  F3A-3. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 
R  =  Retrieval ) : 


Menu  Selection  and  Input  Sequence: 


Ql-n:  The  identifiers  of  values  for  the  up  to  5  types  of 
units  about  which  there  are  factors  that  determine 
the  applicability  of  an  OHMIS  form.  Exact  number  and 
type  of  identifier  (CT10)  or  data  element  type  (CT4) 
are  from  the  DS12  data  located  in  PI.  Query  is  in 
P4. 


Q2-n:  The  values  for  the  up  to  5  characteristics  (data  ele¬ 
ment  types)  for  each  of  the  Ql-n  identifiers  above. 
Exact  number  and  data  element  types  (CT4)  are  from 
DS12  data  located  in  PI.  Query  in  P9. 

Data  Retrievals: 

Rl:  The  type  of  form  code  (CT9)  retained  in  P4  of  Step 

F3A-3. 

R2:  The  completed  form  identifier  (ID18)  retained  in  PI 

of  Step  F3A-3. 

R3:  The  OhMIS  service  area  identifier  ( I DIO )  from  P5  of 

Step  F1A-2. 

R4:  The  Menu  Selection  Sequence  retained  in  PI  of  Step 

F3A-1,  i.e.,  whether  the  user  wishes  only  to  examine 
the  blank  form  or  to  use  it  to  enter  data. 


R5:  The  outstanding  (uncompleted)  forms  monitoring  data 

(DS22)  for  the  ID18  retrieved  in  R2,  if  any. 

DS12:  Forms  applicability  factors  data. 

DS13:  Forms  appl i cab i 1 ity  values  data. 

DL24:  List  of  form  application  identifiers  (ID19)  by  form 
type  code  (CT9)  and  OHMIS  service  area  ( I  DIO ) ;  used 
to  identify  applicable  DS13  data. 


STEP  F3A-4 


PROCESSING 
loop) ) : 

(P  =  Process  Substep;  FN  =  For  Next  (program  logic 

PI: 

Locate  the  0S12  data  for  the  CT9  in  Rl. 

P2: 

Generate  a  blank  temporary  record  (held  throughout 
Function  F3A),  called  the  P2  record,  that  resembles  the 
format  of  the  DS12  data  set  from  PI.  Assign  the  CT9  from 
Rl  and  the  I DIO  from  R3. 

P3: 

Using  the  DS12  data  located  in  Pi,  identify  the  up  to  5 
types  of  units  that  determine  the  appl icabi 1 i ty  of  a  form 

FN1 : 

FOR  each  of  the  up  to  5  types  of  units  from  P3. 

P4: 

Ask  user  for  value  for  the  unit  (Ql-n).  Retain  value  in 
corresponding  field  on  the  P2  temporary  record. 

P5: 

Using  the  DS12  data  located  in  PI,  identify  the  up  to  5 
characteristics  (data  element  types)  that  determine  the 
applicability  of  the  form  for  the  type  of  unit  identified 
in  P3  that  is  covered  by  this  iteration  of  FNl. 

FN1.1: 

FOR  each  of  the  up  to  5  unit  characteristic  (data 
element  types)  from  P5: 

P6: 

Is  the  value  for  this  data  element  type  available  in  the 
current  OHMIS  data  base?  Yes  =  P7;  No  =  P9 

P  7 ; 

Locate  the  value  for  this  data  element  type  and  retain  it 
in  the  corresponding  field  on  the  P2  temporary  record. 

P8: 

GO  TO  PIO. 

P9: 

Ask  user  for  Q2-n,  i.e.,  the  value  for  the  data  element 
type;  store  in  corresponding  field  on  the  P2  temporary 
record.  If  no  answer  is  provided,  GO  TO  Pll. 

PIO: 

NEXT  FNl.l;  end  of  FNl - 1 .  GO  TO  P14. 

Pll : 

Tell  user  that  it  is  not  possible  to  obtain  the 
information  needed  to  select  the  applicable  form. 

P12 : 

Ask  user  if  s/he  wishes  to  use  the  default  version  of  the 
form.  Yes  =  P13;  No  =  PIO  of  Step  F3A-2. 

P13: 

Change  the  answer  to  Ql  of  Step  F3A-2  retained  in  PI  of 
Step  F3A-2  to  a  ' 3' . 

P14: 

GO  TO  P7  of  Step  F3A-3. 

PI  5: 

NEXT  FNl;  end  of  FNl,  GO  TO  P16. 
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P16:  Using  DL24,  locate  all  DS13  data  sets  for  the  CT9  from  R1 

and  the  ID10  from  R3. 

FN2:  FOR  each  set  of  DS13  data  from  P 16 : 

P17:  Do  the  values  for  the  types  of  units  and  the  applicability 

characteristics  stored  in  the  P2  temporary  record  match 
the  corresponding  values  on  the  DS13  data  set?  Yes  =  P18; 
No  =  P20 

P18:  Identify  the  forms  specification  identifier  (ID16)  on  the 

0S13  data  for  this  iteration  of  FN2.  If  R4  is  a  '5',  add 
this  1 016  to  the  DS22  data  retrieved  in  R5.  If  R4  is  *4', 
retain  this  1016  throughout  Function  F3A.  (Triggering 
Step) 

P19:  GO  TO  P10  of  Step  F3A-3. 

P20:  NEXT  FN2 ;  end  of  FN2,  GO  TO  P21. 

P21:  Tell  user  was  not  able  to  find  a  form  that  matched  the 

applicability  values  given  by  the  user. 

P22:  GO  TO  P12. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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Determine  if  the  user  merely  wishes  to  examine  the  blank  form  (i.e., 
not  use  it  for  data  entry).  If  so,  generate  the  blank  form. 

PREVIOUS  STEP:  Step  F3A-5  follows  P10  of  Step  F3A-3. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  The  Menu  Selection  Sequence  retained  in  PI  of  Step 

F3A-1,  i.e.,  whether  the  user  wishes  to  generate  a 
form  for  examination  only  ( ‘ 4 '  )  or  for  use  in  enter¬ 
ing  data  ( *5' ) . 

R2:  The  completed  form  identifier  (ID18)  from  PI  of  Step 

F3A-3. 

R3:  Current  date. 

R4:  Forms  specification  identifier  (ID16)  retained  in  P 7 

or  P9  of  Step  F3A-3  or  P18  of  Step  F3A-4. 

R5:  The  OHMIS  service  area  identifier  (IDIO)  retained  in 

P5  of  Step  F1A-2. 

R6:  The  type  of  form  code  (CT9)  retained  in  P4  of  Step 

F3A-3 . 

DS9:  Current  user/position  identity  and  address  data. 

DS1U:  Forms  description  data. 

DS11:  Forms  subpart  data. 

PROCESSING  (P  =  Process  Substep): 

PI:  Is  Rl  a  '4'  or  a  '5'?  4  =  P2;  5  =  P6 

P2:  Locate  the  DS10  data  that  matches  the  ID16  retrieved  in 

R7. 

P3:  Locate  the  sets  of  DS11  data  that  match  the  forms  subpart 

identifier  (ID17)  given  in  the  DSlU  data  from  P2. 

P4:  Using  the  DS10  data  from  P2  and  the  DS11  data  from  P3, 

obtain  the  data  needed  to  output  the  desired  form,  i.e, 
Output  012.  The  address  data  is  from  DS9.  Assign  the 
ID18  from  R2;  the  CT9  from  R6;  the  I Dl 6  from  R4;  the  R3 
(current  date)  as  the  date  that  the  form  is  generated;  and 
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the  I  DIO  from  R5.  The  remaining  data  on  this  output  is 
from  the  DSIO  data  and  its  corresponding  DS11  data  or  can 
be  left  off  if  not  provided  on  the  DSIO  data. 

P5 :  GO  TO  P10  of  Step  F3A-2. 

P6:  GO  TO  PI  of  Step  F3A-6. 

OUTPUTS  ANO  GENERATION  OF  DATA  SETS: 

012:  OHMIS  blank  form  (generic)  of  the  type  specified  by  the 

user. 


J 
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Obtain  the  information  needed  to  monitor  the  completion  of  each  form 
that  is  to  be  generated  for  use  in  data  entry,  i.e,  obtain  t':o 
outstanding  (uncompleted)  forms  monitoring  data  (DS22).  Also,  fill  in 
as  much  as  possible  of  the  identification  portion  of  the  form  just 
generated.  Determine  if  there  are  any  data  elements  missing  from  the 
OHMIS  data  base  for  the  same  forms  unit(s)  (e.g.,  an  employee)  for 
which  the  user  is  generating  this  form  and,  of  so,  generate  the  DS22 
data  for  the  Missing  Data  Element  Type  Forms  needed  to  collect  this 
missing  information.  Generate  the  blank  forms  specified  by  the  user 
and  any  needed  Missing  Data  Element  Type  Forms. 

PREVIOUS  STEP:  Step  F3A-6  follows  P6  of  Step  F3A-5. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

El:  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position 

identifier  (ID14)  or  employee  identifier  (ID4)  of  the 
person  who  is  supposed  to  complete  the  form,  i.e., 
the  person  to  whom  the  form  is  to  be  sent.  Entry  to 
DS22  in  P9. 

E2:  The  OHMIS  user  identifier  (ID13)  of  the  person  re¬ 

questing  the  data  on  the  form  being  generated  and  the 
person  to  whom  the  completed  form  is  to  be  sent. 

Entry  to  DS22  in  Pll. 

E3:  The  OHMIS  user  identifier  (ID13)  or  OHMIS  position 

identifier  (IU14)  or  employee  identifier  (ID4)  of  the 
person  who  is  supposed  to  review  the  completed  form. 
Entry  to  DS22  in  P22. 

£4:  The  length  of  time  from  the  date  that  the  form  was 

generated  until  the  completed  form  is  due.  Entry  to 
OS 22  in  P27. 


The  values  for  tne  up  to  9 
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(e.g.,  an  employee)  or  thin 
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bes,  e.g.,  a  form  for  a 
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Data  Retrievals: 

Rl:  The  completed  form  identifier  ( I D1 8 )  from  PI  of  Step 

F3A-3. 

R2:  OHMIS  user  identifier  (ID13)  of  the  person  who  last 

logged  onto  the  OHM I S  system  as  retained  in  P2  of 
Step  F1A-1. 

R3:  Next  available  unique  complete  form  identifier 

(ID18). 

DS9:  Current  user/position  identify  and  address  data. 

DS10:  Forms  description  data. 

DS11:  Forms  subpart  data. 

DS19:  Missing  data  element  information. 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data. 

DL8:  OHMIS  user/position  identifier  (ID13/ID14)  by  OHMIS 

user/position  type  (CT1/CT2)  list. 

DL25:  Missing  data  element  list. 

PROCESSING  (P  =  Process  Substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Locate  the  DS22  data  for  the  ID18  from  Rl. 

P2:  Locate  the  DS10  data  for  the  forms  specification 

identifier  (ID16)  in  the  DS22  data  from  PI. 

P3:  Does  the  DS10  data  from  P2  have  a  specification  for  the 

OHMIS  user  type  (CT1)  or  position  type  (CT2)  of  the  type 
of  person  who  is  to  complete  the  form  being  generated? 

Yes  =  P4;  No  =  P9. 

P4:  Using  the  DL8  list,  determine  the  OHMIS  user  identifier 

(1013)  or  OHMIS  position  identifier  (ID14)  that 
corresponds  to  tne  CT1  or  CT2  from  P3  for  the  OHMIS 
service  area  on  the  DS22  data  from  PI. 

PS:  Using  the  DS9  data,  determine  the  employee  identifier 

(IU4)  for  the  ID13  or  ID14  from  P4. 

P6:  Print  the  ID13/ID14  from  P4  and  the  ID4  from  PS.  Ask  the 

user  whether  this  is  the  correct  identify  of  the  person 
who  is  to  complete  the  form  being  generated.  Yes  =  P7; 

No  =  P9 
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P7:  Enter  the  ID13  or  ID14  and  ID4  data  onto  the  0S22  data 

from  PI. 

P8:  GO  TO  P10. 

P9:  Ask  user  for  El.  Enter  the  identifier  (ID13  or  ID14 

and/or  1D4)  infoimation  onto  the  DS22  data  from  PI. 

Obtain  the  missing  identifier  information  (i.e.,  the 
information  not  provided  by  the  user)  from  the  DS9  data 
and  enter  onto  the  DS22  data. 

P10:  Print  the  1013  from  R2.  If  user  if  this  is  the  user 

requesting  the  data  on  the  form  being  generated,  i.e,  is 
this  the  person  to  whom  the  completed  data  should  be  sent? 
Yes  =  P 13 i  No  =  Pll 

P 11 :  Ask  user  for  E2.  Enter  the  ID13  onto  the  0S22  data  from 
PI. 

P12 :  GO  TO  P14 . 

P13:  Enter  the  ID13  from  R2  onto  the  DS22  data  from  PI. 

P14:  Using  DS9,  identify  the  employee  identifier  (ID4)  for  the 

[013  entered  onto  the  0S22  data  in  Pll  or  P13.  Enter  this 
ID4  onto  the  DS22  data  from  PI. 

P15:  Does  the  DS10  data  from  P2  have  a  specification  for  the 

CT1  or  CT2  of  the  type  of  person  who  is  to  review  (sign 
off  on)  the  completed  form  being  generated?  Yes  =  P16; 

No  =  P21 

P 16 :  Using  DL8,  determine  the  ID13  or  ID14  for  the  CT1  or  CT2 

from  P15. 

P17:  Using  the  0S9  data,  determine  the  ID4  for  the  ID13  or  ID14 

from  P 1 6 . 

P18:  Print  the  I013/ID14  from  P16  and  the  104  from  P17.  Ask 

user  whether  this  is  the  correct  identify  of  the  person 
who  is  supposed  to  review  the  completed  form.  Yes  =  P19; 
No  =  P21 

P 19 :  Enter  the  1013  or  ID14  and  ID4  onto  the  DS22  data  from  PI. 

P20:  GO  TO  P23. 

P21 :  Ask  user  if  wishes  to  designate  a  person  who  is  to  review 

the  completed  form.  Yes  =  P22;  No  =  P23 

P22:  Ask  user  for  E3.  Enter  the  identifier  (1013  or  ID14 

and/or  ID4)  onto  the  DS22  data  from  PI.  Obtain  the 
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missing  identifier  (not  provided  by  the  user)  from  the  0S9 
and  enter  onto  the  DS22  data. 

P23:  Does  the  DS1Q  from  P2  contain  specifications  for  the 

length  of  time  to  be  allowed  from  the  time  that  the  form 
is  generated  to  the  time  that  the  form  is  supposed  to  be 
completed  and  returned?  Yes  =  P24;  No  =  P26 

P24:  Enter  the  length  of  time  from  P23  onto  the  DS22  data  from 

PI. 

P25 :  GO  TO  P28. 

P26:  Ask  the  user  is  s/he  wishes  to  specify  the  length  of  time 

in  which  the  form  being  generated  will  be  due.  Yes  =  P27; 
No  •-=  P28. 

P27:  Ask  user  for  E4.  Enter  onto  the  DS22  data  from  PI. 

P28:  Using  the  DS10  data  from  P2,  abstract  the  up  the  9 

identifier  types  (CT10)  and/or  data  element  types  (CT4) 
that  make  up  the  types  of  forms  units  for  the  form  being 
generated.  Put  on  a  temporary  list  called  the  P28  list. 

FN1:  FOR  each  type  of  forms  unit  on  the  P28  list: 

P29:  Ask  user  for  E5-n,  i.e.,  the  value  for  the  forms  unit.  If 

the  user  is  not  able  to  provide  the  value,  GO  TO  P38. 

Enter  value  from  E5-n  onto  the  DS22  data  from  PI. 

P30:  Using  the  DL25  list,  determine  if  there  are  currently  any 

data  elements  missing  from  the  OHMIS  data  base  for  the 
identifier  that  is  the  forms  unit  in  this  iteration  of 
FNl,  i.e.,  the  identifier  entered  in  P29.  Yes  =  P31;  No  = 
P38 

P31 :  Locate  and  put  on  a  temporary  list  all  missing  data 

element  type  information  identifiers  (ID21)  on  DL25  for 
the  forms  unit  in  this  execution  of  FNl,  called  the  P31 
1  ist. 

FNl.l:  FOR  each  ID21  on  the  P 31  list: 

P32:  Locate  the  DS19  data  for  the  ID21. 

P33:  Determine  from  the  DS19  data  from  P32  if  this  data  element 

type  is  already  on  a  Missing  Data  Element  Type  Form. 

Yes  =  P35;  No  =  P34 

P34:  Enter  the  ID21  for  this  execution  of  FNl.l  on  the  DS19 

data  from  P 32  and  on  a  temporary  list,  called  the  P34 
list,  stored  throughout  Step  F3A-6. 
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P35:  NEXT  FN1.1;  end  of  FNl.l,  GO  TO  P36. 

P36:  Are  there  any  I D2 1 s  on  the  P34  list?  Yes  =  P37;  No  =  P38 

P37:  Generate  a  new  set  of  DS22  data  (not  the  same  as  the  DS22 

data  from  Dl)  for  a  new  form.  This  will  be  a  Missing  Data 
Element  Type  Form  and  will  request  the  missing  data  ele¬ 
ment  types  identified  on  the  P34  list  for  the  forms  unit 
in  this  iteration  of  FNl.  Assign  the  ID18  from  R3  to  this 
new  DS22  data  set;  also,  enter  this  ID18  on  the  other 
forms  generated  list  at  the  bottom  of  the  DS22  data  from 
Pi.  (This  provides  a  cross-reference.)  Also,  add  this 
ID18  to  a  temporary  list,  called  the  P37  list.  For  the 
new  DS22  data,  answer  the  question  about  whether  this  is  a 
Missing  Data  Element  Type  Form  with  a  'Yes';  assign  the 
standard  Missing  Data  Element  Type  Form  form  type  code 
(CT9)  that  is  used  for  all  forms  of  this  type;  omit  the 
form  specification  identifier  (ID16);  use  the  identifier 
for  the  forms  unit  for  this  iteration  of  FNl  (i.e.,  the 
value  given  in  P29)  as  the  forms  unit  on  the  new  DS22 
data;  and,  list  the  ID18  from  R1  on  the  other  forms 
generated  list  at  the  bottom  of  this  new  DS22  data  (cross- 
reference).  Copy  from  the  DS22  data  from  PI  to  the  DS22 
data  generated  in  this  Step,  the  following  information: 
the  date  the  DS22  data  was  generated,  the  OHMIS  service 
area  identifier  (ID10),  the  person  to  whom  this  Missing 
Data  Element  Type  Form  should  be  sent  (i.e,  completed  by), 
the  person  to  whom  the  completed  form  should  be  returned, 
and  the  time  before  the  form  is  overdue.  Leave  the  person 
who  should  review  the  completed  form  blank.  List  the 
ID2 1 s  from  the  P34  list  at  the  bottom  of  this  new  DS22 
data  to  indicate  what  types  of  data  element  types  are 
missing  and  are  to  be  gathered  on  this  Missing  Data  Ele¬ 
ment  Type  Form. 

P38:  NEXT  FNl;  end  of  FNl,  GO  TO  P39. 

P39:  Is  there  more  than  one  forms  unit  on  the  P28  list?  Yes  = 

P40;  No  =  P50 

P40:  Generate  a  temporary  list  of  all  possible  combinations 

of  the  forms  units  on  the  P28  list,  called  the  P40  list. 

FN2:  FOR  each  combination  of  forms  unit  identifiers  on  the  P40 

list: 

P41:  Using  0L25,  determine  if  there  are  currently  any  data 

elements  missing  from  the  OHMIS  data  base  for  the 
combination  of  forms  unit  identifiers  in  this  iteration  of 
FN2.  Yes  =  P42;  No  =  P49 
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P42:  Locate  and  put  on  a  list  all  missing  data  element  type 

information  identifiers  (ID21)  on  the  DL25  list  for  the 
combination  of  forms  units  in  this  iteration  of  FN2. 

FN2.1:  FOR  each  ID21  on  the  P42  list. 

P43:  Locate  the  DS19  data  for  the  ID21. 

P44:  Determine  from  the  DS19  data  from  P43  if  this  data  element 

type  is  already  on  the  Missing  Data  Element  Type  Form. 

Yes  =  P46;  No  =  P45 

P45:  Enter  the  1021  for  this  execution  of  FN2.1  on  the  DS19 

data  from  P43  and  on  a  temporary  list  called  the  P45  list. 

P46 :  NEXT  FN2.1;  end  of  FN2.1,  GO  TO  P47. 

P47:  Are  there  any  1021s  on  the  P45  list?  Yes  =  P48;  No  =  P49 

P48:  Generate  a  new  set  of  DS22  data  (not  the  same  as  the  DS22 

data  from  PI  or  P37)  for  a  new  form.  This  will  be  a 
Missing  Data  Element  Type  Form  to  request  the  missing  data 
element  types  identified  on  the  P45  list  for  the  combina¬ 
tion  for  forms  unit  in  this  iteration  of  FN 2.  (Follow  the 
instructions  in  P37,  including  the  addition  of  the  ID18 
for  this  new  set  of  DS22  data  to  the  P37  list.) 

P49:  NEXT  FN2;  end  of  FN2,  GO  TO  P50. 

P50:  Locate  the  sets  of  D511  data  corresponding  to  the  forms 

subpart  identifiers  (ID17)  on  the  DS10  data  from  P2. 

P51:  Using  the  DS22  data  from  PI,  the  DS10  data  from  P2,  and 

the  DS11  data  from  P50,  obtain  the  data  needed  to  output 
the  desired  form,  i.e..  Output  012.  (Follow  the 
instructions  in  P9  of  Step  F3A-2.) 

P52:  Are  there  ID18s  on  the  P37  list  (i.e.,  are  there  any 

Missing  Data  Element  Type  Forms  that  were  generated  during 
Step  F3A-6) ?  Yes  =  P53;  No  =  P10  of  Step  F3A-2 

FN3:  FOR  each  1018  on  the  P37  list: 

P53:  Locate  the  DS22  data  that  matches  the  1018  for  this 

iteration  of  FN3. 

P54:  For  each  of  the  missing  data  element  type  information 

identifiers  (ID21)  on  the  DS22  data  from  P53,  locate  the 
corresponding  DS19  data. 
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P55:  Using  the  0S22  data  from  P53  and  the  DS19  data  from  P 54 , 

obtain  the  data  needed  to  output  the  desired  form,  i.e.. 
Output  012.  (Follow  the  instructions  in  P6  of  Step 
F3A-2.) 

P56:  NEXT  FN3;  end  of  FN3,  GO  TO  P57. 

P57 :  GO  TO  P10  of  Step  F3A-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

012:  OHMIS  blank  form  (generic)  for  the  form  desired  by  the 

user  and  for  each  Missing  Data  Element  Type  Form  generated 
during  Step  F3A-6. 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data. 


FUNCTION  F3B 


Completed  Forms  Data  Entry  and 
Allowable  Limits  Evaluation  Function 
(Functional  Data  Flow) 


This  Functional  Data  Flow  describes  how  data  is  entered  onto  the  OHMIS 
data  base  from  an  OHMIS  form. 

SUMMARY  OF  SUBFUNCTIONS: 

The  following  are  the  subfunctions  to  be  accomplished  under  this  OHMIS 
function: 

1.  Entry  of  data  from  a  completed  OHMIS  form. 

2.  Entry  of  missing  data  elements  onto  the  OHMIS  data  base. 
Missing  data  elements  are  values  that  were  not  available  for 
entry  at  the  time  that  input  was  made  to  the  OHMIS  data  base. 
(Input  can  be  from  an  OHMIS  form,  External  Data  Source  or 
other  sources.) 

3.  For  each  input  to  the  OHMIS  data  base: 

a.  Determine  whether  there  are  any  allowable  limits 
specifications  (DS17)  applicable  to  the  entry  of  this 
input.  The  applicability  of  an  allowable  limit  is 
determined  from  DS15  and  DS16  data.  If  all  of  the 
information  needed  needed  to  determine  whether  an 
allowable  limits  specification  is  applicable  is  not 
available,  maintain  the  allowable  limits  check  request 
data  (DS18)  so  that  the  user  may  input  the  data  needed  to 
make  this  determination  using  Function  F3C  (Allowable 
Limits  Check). 

b.  For  each  applicable  allowable  limits  specification, 
determine  whether  the  value  entered  matches  the  allowable 
limits  specification,  e.g.,  exceeds  an  acceptable  value 
for  a  medical  test  result.  If  the  determination  of 
whether  an  allowable  limits  specification  matches  must  be 
done  manually,  maintain  the  DS18  data  with  which  the  user 
may  make  this  determination  using  Function  F3C. 

c.  For  each  matching  allowable  limits  specification, 
generate  the  requirements  implementation  data  (DS5). 

This  data  will  initiate  the  implementation  and  monitoring 
of  the  actions  required  from  the  entry  of  a  value  that 
matches  an  allowable  limit. 


TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


STEP  F3B-1 


Identify  the  type  and  version  (specification)  of  the  form  being 
entered.  Begin  to  generate  the  completed  form  data  set  (DS14)  for 
storing  the  data  from  the  form  being  entered.  Enter  specifications  of 
the  form  and  the  values  for  the  form  units  on  the  DS14  data. 

PREVIOUS  STEP:  Step  F3B-1  is  executed  whenever  the  user  wishes  to 
enter  data  from  an  OHMIS  form  onto  the  OHMIS  data  base. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  3  (completed  forms  data  and  uncompleted  forms  data) 

S2:  1  (enter  data  from  a  form) 

El:  Completed  forms  identifier  (ID18)  for  the  form  the 

user  is  entering 

E2:  Form  specification  identifier  (ID16)  of  the  form  the 

user  is  entering 

E3:  The  up  to  9  identifiers  or  values  for  the  forms  units 

on  the  form.  The  forms  units  are  the  identification 
portion  of  the  form,  i.e.,  the  person(s)  and/or 
thing(s)  described  by  the  completed  form  data  (DS14). 
The  exact  data  elements  and  format  for  the  forms 
units  are  obtained  from  the  DS10  data  corresponding 
to  the  ID16  from  E2. 

Data  Retrievals: 


Rl: 

Current  date. 

R2 : 

Next  available  unique  completed 
(ID18). 

form  identifier 

DS10 : 

Forms  description  data. 

OS  11: 

Forms  subpart  data. 

0S22 : 

Outstanding  (uncompleted)  forms 

monitoring  data. 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 


PI:  Ask  user  for  El,  i.e.,  the  ID18  that  is  printed  on  the 

form  being  entered.  If  the  user  does  not  have  an  ID18, 
i.e.,  the  user  is  entering  data  directly  onto  an  OHMIS 
computer  screen  and  not  from  a  hard  copy  OHMIS  form  (or  if 
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the  user  accidentally  used  a  OHMIS  form  generated  for 
examination  only,  i.e.,  not  for  data  entry)  use  the  ID18 
from  R2.  Retain  this  ID18  throughout  Function  F3B. 

P2:  Is  there  a  set  of  DS22  data  for  the  ID18  entered  in  PI? 

Retain  answer  throughout  Function  F3B.  Yes  =  P3;  No  =  P4 

P  3 :  GO  TO  P16 . 

P4:  Begin  generating  a  new  set  of  DS22  data.  Assign  the  ID18 

from  PI.  Assign  the  R1  as  the  date  the  DS22  data  was 
generated.  Answer  the  Missing  Data  Element  Type  Form 
question  on  the  DS22  data  set  as  'No'. 

P5:  Ask  user  for  E2,  i.e.,  the  ID16  that  is  printed  on  the 

form  being  entered.  If  the  user  is  entering  directly  onto 
the  screen  (not  from  a  hard  copy  form),  the  user  must 
provide  the  ID16.  Retain  this  1D16  throughout  Function 
F38.  Enter  onto  the  DS22  data  from  P4. 

P6:  Locate  the  OSIO  data  for  the  ID16  from  P5  or  P19.  Use 

this  DS10  data  throughout  Function  F3B  to  provide  entries 
and  guidelines  for  checking  (editing)  for  entries  of  data 
from  the  form;  i.e.,  this  DS10  data  indicates  field 
locations  and  data  element  type  editing  instructions  for 
the  data  being  entered  on  the  form. 

P7:  Locate  each  of  the  sets  of  DSll  data  referenced  by  the 

forms  subpart  identifiers  ( IDl 7 )  on  the  DS10  data  from  P6. 
Retain  these  IDl 7 s  throughout  Function  F3B. 

P8:  Begin  generating  a  new  set  of  DS14  data.  Use  the  field 

format  specified  by  the  DS10  data  from  P6  and  the  DSll 
data  sets  from  P7.  Assign  the  1D18  from  PI  and  the  ID16 
from  P5  or  P19. 

P9:  Is  the  answer  retained  in  P2  (previous  DS22  data).  A 

'Yes'?  Yes  =  P21;  No  =  P10 

PIG:  Locate  the  form  type  code  (CT9)  and  OHMIS  service  area 

identifier  ( I  DIO )  on  the  DS10  data  from  P6.  Assign  these 
values  to  the  DS22  data  from  P4  and  the  DS14  data  in  P8. 

P 11 :  Locate  the  length  of  time  that  the  hard  copy  of  the  form 

is  to  be  maintained  from  the  DS10  data  from  P6.  Add  to 
the  DS14  data  in  P8. 

P12:  Generate  a  data  entry  screen  version  of  output  012  for 

the  user  to  enter  data  from  the  form.  This  screen  should 
follow  the  format  of  012  for  the  DS 1 4  data  generated  in  P8 
and  include  the  0S14  data  elements  completed  in  P8,  P 10 
(or  P21)  and  PI 1 . 
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P13:  Is  the  answer  retained  in  P2  (previous  DS22)  a  'Yes'?  Yes 

=  P23;  No  =  P14 

P14:  Ask  user  for  £3,  i.e.,  the  forms  units  for  the  form  being 

entered.  Note:  As  with  the  remaining  data  entries  in 
F3B,  the  user  enters  the  data  for  the  hard  copy  of  the 
completed  form  onto  the  portion  of  the  data  entry  screen 
that  looks  exactly  like  the  hard  copy  form  (or  fills  in 
the  'blanks'  on  the  screen  directly  without  a  hard  copy 
form).  At  each  entry  the  program  checks  against  the 
format  for  the  DS14  data  generated  in  P8  to  determine  if 
the  data  has  been  entered  correctly,  i.e.,  the  right  type 
and  range  of  values  for  the  data  element  type  given  on  the 
DS14  data.  Enter  E3  onto  the  DS14  data  from  P8  and  the 
DS22  data  from  P4  (or  P16). 

P16:  Find  the  DS22  data  corresponding  to  the  1018  from  PI. 

PI 7 :  Does  the  DS22  data  from  P16  indicate  that  the  form  being 

entered  is  a  Missing  Data  Element  Type  Form?  Yes  =  P18; 

No  =  P19 

P18:  GO  TO  PI  of  Step  F3B-7. 

P 19 :  Identify  the  forms  specification  identifier  (ID16)  for  the 

form  being  entered  from  the  DS22  data  from  P16. 

P20:  GO  TO  P6. 

P21:  Copy  the  CT9,  I DIO  and  forms  unit  identifiers  on  the  DS22 

data  from  P 16  to  the  DS14  data  in  P8. 

P22 :  GO  TO  Pll. 

P23:  Ask  the  user  whether  the  forms  unit  identifiers  shown  on 

the  output  012  (obtained  from  the  DS22  data)  are  all 
correct.  Yes  =  P15;  No  =  P14 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

012:  OHM  1 5  blank  form  (generic),  screen  version,  i.e.,  with  the 

lines  about  who  is  supposed  to  complete  the  form  and 
review  it  and  the  line  about  who  requested  the  data  left 
off  of  the  output.  Screen  version  has  instructions  for 
entering  data  elements. 

D814:  Completed  form  data. 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data. 
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Obtain  and  <  ock  the  date  and  person  completing  the  form  and  the  date 

and  person  reviewing  the  form. 

PREVIOUS  STEP:  Step  F3B-2  follows  P15  of  Step  F3B-1. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

El:  The  date  that  the  data  on  the  form  was  collected 

(i.e.,  the  date  on  which  the  data  to  fill  out  the 
form  was  obtained;  not  the  date  that  the  form  was 
completed  and  not  the  date  that  it  was  entered, 
although  these  dates  could  be  the  same  as  the  date 
that  the  data  was  collected).  For  some  forms,  this 
will  include  the  time  that  the  data  was  collected  as 
well  as  the  date. 

E2:  An  employee  identifier  (ID4)  for  the  person  who 

completed  the  form  being  entered. 

E3:  Explanation  of  any  difference  between  the  person  who 

was  supposed  to  complete  the  form  being  entered  (as 
specified  on  the  DS10  data)  and  the  person  who 
actually  did  complete  the  form. 

E4:  Employee  identifier  ( ID4)  for  the  person,  if  any,  who 

reviewed  (signed  off  on)  the  form  being  entered. 

E5:  Date  form  was  reviewed. 

E6:  Explanation  of  any  difference  between  the  person  wh 

was  supposed  to  review  the  completed  form  (as 
specified  on  the  DS10  data)  and  the  person  who 
actually  did  review  the  form. 

Data  Retrievals: 

Rl:  Completed  form  identifier  ( ID18)  from  PI  of  Step 

F  38-1 . 

DS9:  Current  user/position  identity  and  address  data. 

DS10:  Forms  description  data. 

DS14:  Completed  forms  data. 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data. 

UL3:  OUMIS  user/pos i t ion  identifier  (ID13/ID14)  by  0HM1S 

user/position  type  (CT1/CT2)  list. 
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PROCESS ING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Locate  the  OSH  data  and  the  DS22  data  from  the  1018  from 

Rl.  Locate  the  DS10  data  corresponding  to  the  forms 
specification  identifier  (1D16)  on  the  OSH  data. 

Generate  the  screen  version  of  the  output  012 
corresponding  to  the  DS 1 4  data. 

P2:  Ask  user  for  El,  i.e.,  data  collection  date.  Enter  onto 

the  OSH  data  from  PI. 

P3:  Ask  user  for  E2,  i.e.,  104  for  the  person  completing  the 

form.  Enter  onto  the  DS 14  data  from  PI. 

P4:  Locate  the  OHMIS  user  identifier  (ID13)  or  position 

identifier  (1014),  if  any,  corresponding  to  the  1D4  from 
P3  using  DS9.  Enter  the  ID13/ID14  onto  the  DS 1 4  data  from 
PI. 

P5:  Does  the  OSIO  data  from  PI  specify  a  particular  type  of 

user/position  code  (CT1/CT2)  for  the  person  who  is 
supposed  to  complete  the  specification  of  the  form?  Yes  = 
P6;  No  =P9 

P6:  Locate  the  CT1/CT2  corresponding  to  the  ID13/ID14  from  P4, 

using  DL8. 

P7:  Does  the  CT1/CT2  identified  in  P6  match  the  CT1/CT2 

specified  in  the  DS10  data  from  PI?  Yes  =  P9;  No  =  P8 

P8:  Tell  the  user  that  the  correct  person  did  not  complete  the 

form.  Tell  user  the  CT1/CT2  of  the  person  who  should  have 
completed  the  form  (from  the  DS10  data)  and  who  did 
complete  the  form  (from  P6).  Ask  user  for  explanation  of 
difference,  i.e.,  E3.  Enter  answer  onto  the  DS14  data 
from  PI. 

P9:  Does  the  DS10  data  specify  that  the  form  being  entered  is 

to  be  reviewed?  Yes  =  P10;  No  =  P 1 7 

P10:  Ask  user  for  the  E4,  i.e.,  the  ID4  of  the  person  reviewing 

the  form.  Enter  onto  the  DS14  data  from  PI. 

P 11 :  Locate  the  ID13/I0H,  if  any,  from  the  ID4  from  P10  using 

DS9.  Enter  the  ID13/ID14  onto  the  OSH  data  from  PI. 

P 1 2 :  Does  the  OS  10  data  from  PI  specify  a  particular  type  of 

user/position  code  (CT1/CT2)  that  is  supposed  to  review 
this  specification  of  the  form?  Yes  =  P13;  No  =  P16 

P13:  Locate  the  CT1/CT2  corresponding  to  the  ID13/1D14  from  Pll 

using  DL8. 
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P 14 :  Does  the  CT1/CT2  identified  in  P13  match  the  CT1/CT2 

specified  in  the  DSIO  data  from  PI?  Yes  =  P16;  No  =  P 1 5 

P15:  Tell  user  that  correct  person  did  not  review  the  form. 

Tell  user  the  CT1/CT2  of  the  person  who  should  have 
reviewed  the  form  (from  the  DSIO  data)  and  who  did  review 
the  form  (from  P13).  Ask  user  for  explanation  of 
different,  i.e.,  E6.  Enter  answer  onto  the  DS14  data  from 
PI. 

Pi6:  Ask  user  for  E5,  i.e.,  date  form  reviewed. 

P17 :  GO  TO  PI  of  Step  F3B-3. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

012:  OHMIS  blank  form  (generic),  screen  version,  i.e.,  as 

described  in  Step  F3B-1. 
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Enter  the  values  for  the  form  onto  the  completed  forms  data  (DS14). 
Generate  missing  data  element  type  information  (DS19)  for  those  data 
element  types  that  were  not  entered. 

PREVIOUS  STEP:  otep  F3B-3  follows  P17  of  Step  F3B-2. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored);  R 
=  Retrieval): 

Menu  Selection  and  Input  Sequence 

El-n  Values  for  each  of  the  data  element  types  on  a 

particular  form  subpart  (DS11)  for  a  form,  ’.e.,  the 
data  being  entered  onto  the  OHM F S  data  base  from  this 
OHM  IS  form 

Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  retained  in  P2  of 

Step  F3B-I 

R2:  Form  subpart  identifiers  (ID17)  that  identify  the 

data  element  types  on  the  form  being  completed.  From 
P 7  of  Step  F3B-1. 

R3:  Current  date 

R4:  Next  available  missing  data  element  type  information 

identifier  (ID21) 

DS10:  Forms  description  data 

DSli:  Forms  subpart  data 

DSI4:  Completed  forms  data 

DL25:  Missing  data  element  list 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Locate  the  DS14  data  with  the  1018  from  Rl;  locate  the 

DS10  data  with  the  IQlb  on  this  OS  1 4  data. 

F_Nlj _ FOR  each  1017  on  the  list  in  R2: 

P2:  Find  the  corresponding  DS11  data.  Use  this  data  to 

determine  the  types  of  data  elements  and  their  editing 
requirements  for  each  data  element  type  being  entered  from 
the  OHM  IS  form  onto  the  OHM  IS  data  base. 


i 
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FNl.l:  FOR  each  of  the  up  to  6  data  element  type  codes  (CT4)  on 

the  DS11  data  from  P2,  i.e.,  on  this  iteration  of  FNl: 

Ask  the  user  for  El-n,  i.e.,  the  value  for  the  data 
element  type  in  this  iteration  of  FNl.l. 

P4:  Did  the  user  provide  a  value  for  the  El-n  in  P 3?  Yes  = 

P9;  No  (i.e.,  does  not  have  the  information  to  complete 
the  entire  form)  =  P5 

P5:  Generate  a  new  set  of  DS19  data.  Assign  the  ID21  from  R4, 

the  data  element  type  code  (CT4)  for  this  iteration  of 

FNl.l,  the  date  from  R3,  and  the  ID18  from  $1,  i.e.,  the 
ID18  for  the  form  from  which  the  value  for  this  data 
element  type  is  missing.  Determine  the  location  in  which 
the  value  for  this  data  element  type  will  be  stored  and 
enter  onto  the  DS19  data.  Using  the  DS10  data  from  Pi, 
identify  which  of  the  up  to  9  forms  unit  identifiers  or 
other  data  element  types  on  the  DS14  data  from  PI 
constitute  the  up  to  6  forms  unit  identifiers  for  the 
subform  part  ( 1 D 1 7 )  in  this  iteration  of  FNl.  Place  these 
forms  unit  identifiers  on  the  DS 19  data. 

P6:  Add  the  ID21  assigned  to  the  DS19  data  in  P5  onto  the  DL25 

list. 

P7:  Assign  a  code  (e.g.,  *  Y 1 )  to  the  two  fields  on  the  DS 1 4 

data  on  Pi  that  correspond  to  the  Data  Element  Sequence 
Number  and  baseline  information  fields  for  the  data 
element  in  this  iteration  of  FNl.l.  (See  DS10  and  DS 14 
for  an  explanation  of  these  two  fields.)  This  code 
indicates  that  there  is  no  Data  Cement  Sequence  Number  or 
baseline  information  for  this  data  element,  because  no 
value  for  the  data  element  type  has  been  entered. 

P8:  GO  TO  P1U. 

P9:  Add  the  value  for  the  data  element  type  entered  in  P3  to 

the  appropriate  field  on  the  DS 1 4  data  from  PI. 

P10:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  Pll. 

PI 1 :  NEXT  FNl;  end  of  FNl,  GO  TO  P12. 

P12 :  GO  TO  PI  of  Step  F3B-4. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS : 

DS19:  Missing  data  element  information 
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Begin  process  of  assigning  Data  Element  Sequence  Numbers  and  baseline 
information  to  each  data  element  on  the  form  that  is  being  entered 
onto  the  OHMIS  data  base.  Complete  the  Data  Element  Sequence 
Number/baseline  information  for  data  elements  that  are  not  entered  on 
the  form  at  this  time,  for  'one-time'  (non-changing)  data  entries  and 
for  'no  baseline  information'  data  entries. 

PREVIOUS  STEP:  Step  F3B-4  follows  P12  of  Step  F3B-3. 

INPUTS  (R  =  Retrieval): 


Menu  Selection  and  Input  Sequence:  None 


Data  Retrievals: 

Rl: 

Completed  form  identifier 
Step  F38-1 

(ID18)  retained  in  PI  of 

R2: 

Form  subpart  identifiers 
data  element  types  on  the 
P 7  of  Step  F3B-1 . 

(ID17)  that  identify  the 
form  being  completed.  From 

DS 11: 

Forms  subpart  data 

DS14 : 

Completed  forms  data 

PROCESSING  (P  = 

Process  substep;  FN  =  For 

Next  (program  logic 

loop) ) : 

PI:  Tell  user  now  beginning  process  of  looking  for  the  ■ 

Element  Sequence  Number  and  baseline  information  fo'  =ach 
of  the  data  element  types  just  entered  on  the  form.  (See 
DS10  and  DS14  for  explanation  of  the  terms  'Data  Element 
Sequence  Number'  and  'baseline  information'.) 

P2:  Locate  the  DS14  data  with  the  . D18  from  Rl;  locate  the 

DSIO  data  with  the  1016  on  this  DS14  data. 

P3:  Using  the  DS1U  data  from  P2,  determine  if  this  is  a 

one-time  form.  Yes  =  P 4 ;  No  =  P7 

P4:  Assign  a  code  (e.g.,  'X')  to  all  unfilled  sets  of  Sequence 

Number/baseline  information  fields.  This  code  indicates 
that  the  data  element  type  does  not  have  a  Sequence 
Number,  because  it  is  a  one-time  entry  (i.e.,  non-changing 
data  such  as  a  person's  date  of  birth)  and  that, 
therefore,  this  is  not  the  type  of  information  that  has  a 
baseline  value  either. 

P5:  Remove  the  ' Y '  code  (no  data  entry)  from  all  Sequence 

Number  and  baseline  information  fields  on  the  DS14  data 
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from  P2,  i.e.,  change  these  fields  to  be  blank  rather  than 
containing  a  1 Y' . 

P6:  GO  TO  PI  of  Step  F3B-8. 

P 7 :  Make  a  temporary  list,  called  the  P7  list,  containing  the 

form  subpart  identifiers  (1017)  on  this  form  (i.e.,  this 
DS14  data  as  identified  in  P2)  that  have  any  data  element 
types  that  have  unf i 1  led  Sequence  Number/baseline 
information  fields.  Use  the  list  from  R2  to  identify  the 
form  subparts  on  the  form  that  should  be  reviewed  to 
determine  if  their  Sequence  Number/baseline  information 
fields  are  filled. 

FNl:  FOR  each  1017  on  the  P7  list: 

P8:  Locate  the  0S11  data  corresponding  to  this  ID17. 

FNl.l:  FOR  each  of  the  up  to  6  data  element  type  codes  (CT4)  on 
the  DS11  data  from  P8  (i.e.,  on  this  iteration  of  FNl): 

P9:  Is  the  Sequence  Number  field  on  the  DS14  data  from  P2  for 

this  data  element  type  filled  with  a  ' Y 1 ?  Yes  =  P12 ;  No  = 
P10 

PIG:  Using  the  DS11  data  for  this  iteration  of  FNl,  determine 

if  the  data  element  type  for  this  iteration  of  FNl.l  is  a 

one-time  (non-changing)  type  of  data  element.  Yes  =  Pll ; 
No  =  P12 

Pll:  Assign  and  code  of  ‘ X *  to  the  Sequence  Number  and  baseline 

information  fields  for  this  data  element  type  on  the  DS14 
data  from  P2. 

P12:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P13. 

P13:  NEXT  FNl;  end  of  FNl,  GO  TO  P14. 

P14:  Using  the  OSIO  data  from  P2,  determine  if  this  is  a  'no 

baseline  information'  type  of  form.  Yes  =  P15;  No  =  P17 

P 15 :  Assign  a  code  of  'X*  to  all  unf i 1  led  baseline 

information  fields  on  the  DS14  data  from  P2. 

P 16 :  GO  TO  P24 . 

Pi 7 :  Make  a  temporary  list,  called  the  P17  list,  containing  the 

form  subpart  identifiers  (ID17)  on  this  form  (DS14  data) 
that  have  unf i 1  led  baseline  information  fields.  Use  the 
list  in  P7  to  generate  this  list. 


FN2: 


FOR  each  ID17  on  the  P 1 7  list: 
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P18:  Locate  the  0S11  data  corresponding  to  this  ID17. 

FN2.1  FOR  each  of  the  up  to  6  data  element  type  codes  (CT4)  on 
the  DS11  data  from  P18  (i.e.,  on  this  iteration  of  FN2): 

P19:  Is  the  baseline  information  field  on  the  DS14  data  from  P2 

for  this  data  element  type  filled?  Yes  =  P22;  No  =  P20 

P20:  Using  the  DS11  data  for  this  iteration  of  FN2,  determine 

if  the  data  element  type  of  this  iteration  of  FN2.1  is  a 
'no  baseline  information1  type  of  data  element.  Yes  = 

P21 ;  No  =  P22 

P21:  Place  a  code  of  'X'  to  the  baseline  information  field  for 

the  data  element  type  in  this  iteration  of  FN2.1  on  the 
DS14  data  from  P2. 

P22:  NEXT  FN2.1;  end  of  FN2.1,  60  TO  P23. 


P23:  NEXT  FN2 ;  end  of  FN2 ,  GO  TO  P24. 


P24 :  GO  TO  PI  of  Step  F3B-5. 

OUTPUTS  AND  GENERATION  OF  OATA  SETS:  None 
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Identify  the  sequence  numbers  and  base  line  information  for  each  data 
element  type  on  the  form  being  entered.  The  processes  in  this  step 
are  for  data  element  types  on  forms  that  have  not  been  previously 
entered  on  the  OHMIS  data  base  for  this  form  unit(s)  (e.g.,  an 
employee)  before  and,  therefore,  the  sequence  number,  if  applicable, 
is  always  '1*  and  the  base  line  information,  if  applicable,  is  always 
'O'  (original  base  line).  This  Step  also  includes  the  processes  for 
assigning  sequence  numbers  and  base  line  information  for  data  element 
types  on  a  form  type  and  for  a  form  unit  for  which  all  past  OHMIS 
forms  of  this  type  and  for  this  forms  unit  have  been  entered  in  the 
correct  order,  i.e.,  the  forms  were  entered  on  the  OHMIS  data  base  in 
the  same  order  as  the  data  on  the  forms  was  collected  and,  therefore, 
all  sequence  numbers  and  base  line  information  for  previously  entered 
forms  of  this  type  and  for  this  forms  unit  are  correct. 

PREVIOUS  STEP:  Step  F3B-5  follows  P24  of  Step  F3B-4. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

El-n:  The  data  element  types  codes  (CT4)  on  the  form  that 
the  user  wishes  to  be  treated  as  secondary  base  line 
entries. 

Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  retained  in  PI  of 

Step  F3B-1. 

R2:  The  list  of  forms  subpart  identifiers  (ID17)  that 

identify  the  data  element  types  on  the  form  begin 
completed  for  which  all  of  the  sequence  number  and 
base  line  information  fields  are  filled.  From  P7  of 
Step  F38-4. 

OS  1 1 :  Forms  subpart  data. 

DS14:  Completed  forms  data. 

0123:  Current  forms  list. 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop))  : 

PI:  Locate  the  DS14  data  with  the  ID18  from  Rl;  locate  the 

DSlU  data  with  the  1016  on  this  DS 14  data. 

P2:  Make  a  temporary  list,  called  the  P2  list,  containing  the 

form  subpart  identifiers  (ID17)  on  the  form  being  entered 
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(i.e.,  the  above  DS14  data)  that  have  unfilled  sequence 
numbers.  Use  the  R2  list  to  generate  this  list. 

P3:  Locate  the  forms  unit(s)  and  the  form  type  (CT9)  for  the 

form  being  entered  (from  the  DS14  data).  Retain  this 
information  throughout  Function  F3B.  Is  there  an  ID18  on 
the  DL23  for  this  form  type  and  forms  unit(s),  i.e.,  have 
any  previous  forms  of  the  same  type  been  entered  onto  the 
OHMIS  data  base  for  the  same  forms  unit(s)  (e.g.,  for  the 
same  employee,  facility,  etc.)?  Yes  =  P 13 ;  No  =  P4 

P4:  Add  the  ID18  from  R1  and  the  form  type  and  forms  unit(s) 

from  P3  to  the  0123  list. 

FNl:  FOR  each  ID  17  on  the  P2  list: 

P5:  Locate  the  corresponding  DS11  data. 

FNl.l:  FOR  each  of  the  up  to  6  data  element  type  codes  (CT4)  on 
the  DS11  from  P5  (i.e.,  the  DS11  for  this  iteration  of 
FNl): 

P6:  Is  the  sequence  number  on  the  DS14  data  from  Pi  for  this 

data  element  type  filled?  Yes  =  P10;  No  =  P7 

P7:  Assign  a  1 1‘  to  the  sequence  number  field  for  this  data 

element  type,  i.e.,  fill  the  sequence  number  field  for 
this  data  element  type  on  the  DS14  data  from  Pi  with  a 
T  . 

P8:  Is  the  base  line  information  field  for  this  data  element 

type  filled?  (Use  the  DS14  data  from  PI  to  determine 
this.)  Yes  =  P10;  No  =  P9 

P9:  Assign  a  code  (e.g.,  'the  letter  O')  to  the  base  line 

information  field  for  this  data  element  type  on  the  DS14 
data  from  PI.  The  code  '0'  means  that  this  data  entry 
constitutes  the  original  base  line  value  for  the  forms 
unit(s)  and  type  of  form  shown  on  this  form  (i.e.,  from 
the  DS14  data  from  PI  as  identified  in  P3). 

P10:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  Pll. 

PI  1 :  NEXT  FNl;  end  of  FNl,  GO  TO  P12. 

P12 :  GO  TO  P5  of  Step  F3B-4. 

P13:  Start  a  temporary  list,  called  the  P13  list,  consisting  of 

pairs  of  ID18s  and  dates.  Place  the  ID18  from  Rl  and  the 
date  that  the  data  on  this  form  was  obtained  (from  the 
DS14  data  from  PI)  at  the  top  (beginning)  of  this  list. 
(Note:  The  order  in  which  these  pairs  of  data  are  added 
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to  the  P13  list  is  important.  Also,  if  this  is  the  type 
of  form  that  contains  information  on  the  time  at  which 
the  data  on  the  form  was  collected  (i.e.,  not  just  the 
date,  but  also  the  hour,  minutes,  seconds,  etc.)  put  this 
time  information  on  the  P 13  list. 

P14:  Locate  the  previous  ID18  on  the  DL23  list  for  the  1018 

from  PI  and  the  form  type/forms  unit(s)  from  P3. 

P15:  Locate  the  0S14  data  for  the  previous  ID18  identified  in 

the  last  step  (i.e.,  identified  in  either  P14  or  P18). 

P 16 :  Place  the  1018  and  the  date  that  the  data  was  obtained  for 

the  DS14  data  identified  in  P15  on  the  bottom  (end)  of  the 
P13  list. 

P17:  Does  the  DS14  data  from  P 15  contain  a  previous  ID18? 

Yes  =  P18;  No  =  P19 

P18:  Identify  the  previous  1018  on  the  DS14  data  from  P15. 

GO  TO  PIS. 

P19:  Are  the  dates  that  data  was  obtained  shown  on  the  P13  list 

without  exception  in  reverse  order  from  latest  to 
earliest  date,  i.e.,  as  you  go  down  the  list  does  each 
date  get  progressively  earlier  (or  remain  the  same  as  the 
date  for  the  previous  date  on  the  list)?  (Note:  If  the 
list  contains  time  information  (as  well  as  date 
information) ,  check  that  the  sets  of  time  information  for 
each  date  are  also  in  reverse  order  from  latest  to 
earliest  time.)  Yes  (i.e.,  the  forms  of  this  form  type 
and  for  this  forms  unit  have  been  entered  onto  the  OHMIS 
data  base  in  the  order  that  the  data  on  the  forms  was 
collected)  =  P20;  No  =  P57 

P20:  Take  the  previous  1018  on  the  DL23  identified  in  P14  and 

put  it  in  the  previous  ID18  field  on  the  DS 14  data  from 
PI.  On  the  DL23  list  replace  the  previous  ID18 
identified  in  P 14  with  the  current  ID18  from  Rl. 

P21 :  Remove  the  first  (top)  I D 18  from  the  P13  list,  i.e.,  the 

current  1018.  The  new  list  is  called  the  P21  list. 

FN2 :  FOR  each  1017  on  the  P2  list: 

P22:  Locate  the  corresponding  DS11  data. 

P23:  Is  the  sequence  number  field  on  the  DS14  data  from  Pi  for 

this  data  element  type  filled?  Yes  =  P50;  No  =  FN  2.1.1 
(P24 ) 


FN2.1.1:  FOR  each  of  the  1018s  on  the  P21  list,  i.e.,  each 

previous  ID18  for  this  type  of  form  and  forms  unit(s): 

P24:  Locate  the  DS14  data  corresponding  to  this  ID18.  Locate 

the  DS10  data  corresponding  to  the  forms  specification 
identifier  (ID16)  on  this  DS14  data. 

P25 :  Is  the  1016  on  the  DS14  data  for  the  form  being  entered 

(from  PI)  the  same  as  the  1016  on  this  previous  DS14  data, 
i.e.,  the  DS14  data  from  P24  corresponding  to  the  1018  for 
this  iteration  of  FN2.1.1?  Yes  (i.e.,  it  is  certain  that 
there  is  a  field  for  the  data  element  type  from  this 
iteration  of  FN2.1  on  the  previous  DS14  data  for  this 
iteration  of  FN2.1.1,  because  both  forms  have  the  same 
forms  specification)  =  P26;  No  =  P28 

P26:  Using  the  DS11  data  from  P22,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FN2.1  on  the 
previous  DS14  data,  i.e.,  the  DS 14  data  corresponding  to 
the  1018  for  this  iteration  of  FN2.1.1. 

P27 :  GO  TO  P39. 

P28:  Identify  each  of  the  ID17s  on  the  DS1U  data  located  in  P24 

(i.e.,  the  forms  subparts  in  the  forms  description  (DS10) 
corresponding  to  the  previous  set  of  DS14  data  form  this 
iteration  of  FN2.1.1).  Put  on  a  temporary  list,  called 
the  P28  list. 

FN2. 1.1,1:  FOR  each  ID17  on  the  P28  list: 

P29:  Locate  the  DS11  data  for  this  ID17. 

P30:  Comparing  the  information  on  the  DS11  data  from  P29  with 

the  DS11  from  P22,  do  the  2  sets  of  forms  subpart  data 
both  refer  to  the  same  exact  form  unit  (or  combination  of 
forms  units)  on  their  respected  DS14  data?  Yes  =  P31;  No 
=  P38 

P3i:  Is  the  1017  for  this  iteration  of  FN2. 1.1.1  the  same  as 

the  ID17  for  this  iteration  of  FN2?  Yes  (i.e.,  it  is 
certain  that  there  is  a  field  for  the  data  element  type 
for  this  iteration  of  FN2.1  on  the  previous  OSH  data  for 
this  iteration  of  FN2.1.1)  =  P32;  No  =  FN2.1.1.1.1  (P34) 

P32:  Using  the  DS11  data  from  P29,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FN2.1  on  this 
previous  OSH  data,  i.e.,  the  DS14  data  corresponding  to 
the  1018  for  this  iteration  of  FN2.1.1. 
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FN2.1.1.1.1:  FOR  each  of  the  up  to  6  data  element  types  on  the 
DS11  data  from  P29  (i.e.,  for  this  iteration  of 
FN2. 1.1.1): 

P34:  Is  this  the  same  data  element  type  as  the  data  element 

type  in  this  iteration  of  FN2.I?  Yes  (i.e.,  it  is  certain 
that  there  is  a  field  for  the  data  element  type  for  this 
iteration  of  FN2.1  on  the  previous  DS14  data  for  this 
iteration  of  FN2.1.1)  =  P35;  No  =  P37 

P35:  Locate  the  field  for  the  data  element  type  in  this 

iteration  of  FN2.1  for  this  previous  DS14  data  (the  DS14 
data  corresponding  to  the  ID18  in  this  iteration  of 
FN2.1.1),  i.e.,  locate  the  field  in  which  the  data  element 
type  in  this  iteration  of  FN2.1.1.1.1  was  reached. 

P 3 7 :  NEXT  FN2.1.1.1.1;  end  of  FN2.1.1.1.1,  GO  TO  P38. 

P38:  NEXT  FN2. 1.1.1;  END  OF  FN2. 1.1.1,  GO  TO  P46. 

P39:  Flag  the  field  on  the  previous  DS14  data  (i.e.,  the  DS14 

data  corresponding  to  the  ID18  for  this  iteration  of 
FN2.1.1)  that  is  the  space  for  the  data  element  type  in 
this  iteration  of  FN2.1,  i.e.,  flag  the  field  identified 
in  P26  or  in  P32  or  in  P35. 

P40 :  Is  there  a  value  entered  on  the  previous  DS 14  data  from 

P24  in  the  field  flagged  in  P39?  Yes  =  P41;  No  =  P46 

P41 :  Locate  the  sequence  number  from  the  data  element  type 

flagged  in  P39  (in  the  sequence  number  field  for  this  data 

element  type  on  the  0S14  data  from  P24).  Add  1 1‘  to  this 
sequence  number.  Place  this  new  sequence  number  on  the 
DS14  data  from  Pi  as  the  sequence  number  of  the  data 
element  type  in  this  iteration  of  FN2.1 

P42:  Is  the  base  line  information  field  for  the  data  element 

type  in  this  iteration  of  FN2.1  a  'no  base  line 
information'  type  of  data  element  type,  i.e.,  is  the  base 
line  information  field  for  this  data  element  type  on  the 
DS14  data  from  PI  already  filled  with  an  'X'?  Yes  =  P50; 
No  =  P43 

P43:  Assign  a  code  (e.g.,  * N ‘ )  to  the  base  line  information 

field  on  the  0514  data  from  PI  for  the  data  element  type 
for  this  iteration  of  FN2.1.  The  ' N '  indicates  that  this 
value  for  the  data  element  type  is  not  a  base  line  value. 

P44:  (Skip  this  process  substep) 


P4a  : 


GO  TO  P50 . 
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P46:  NEXT  FN2.1;  end  FN2.1.1,  60  TO  P47. 

P47 :  Place  the  sequence  number  *  1 ‘  in  the  sequence  number  field 

for  the  data  element  type  in  tms  iteration  of  FN2.1, 
i.e.,  on  the  DS14  data  from  PI. 

P48:  Is  the  baseline  information  field  for  the  data  element 

type  in  this  iteration  ot  FN2.1  a  'no  base  line 
information1  type  of  data  element,  i.e.,  is  the  base  line 
information  field  for  this  data  element  type  on  the  DS 14 
data  from  PI  already  filled  with  an  ' x  *  ?  Yes  =  P  50 ;  No  = 
P49 

P 49 :  Assign  the  code  ‘O'  (original  base  line)  to  the  base 

line  information  field  on  the  DS14  data  from  Pi  for  the 
data  element  type  in  this  iteration  of  FN2.1. 

P50:  NEXT  FN2.1;  end  of  FN2.1,  Go  TO  P51 . 

P51 :  NEXT  FN2 ;  end  of  FN2,  GO  TO  P52. 

P52:  Review  each  of  the  base  line  information  fields  on  the 

DS14  data  from  Pi.  If  the  base  line  information  field  is 
filled  with  an  1 N '  (not  a  base  line  entry),  put  the  data 
element  type  code  (CT4)  corresponding  to  this  field  on  a 
temporary  list,  called  the  P52  list. 

P53:  Are  there  any  data  element  type  codes  (CT4)  on  the  P52 

list?  Yes  =  P54 ;  No  =  P56 

P54:  Ask  user  if  s/he  wishes  to  identify  any  of  the  data 

element  type  codes  on  the  form  just  entered  as  'secondary 
base  line'  information,  i.e.,  as  entries  that  are  not  the 
first  entry  of  the  data  element  type  for  this  forms  unit 
on  the  OHMIS  data  base  (i.e.,  not  the  original  base  line 
entry),  but  are  nevertheless  to  be  treated  as  base  line 
information.  Yes  =  P55;  No  =  P56 

P55 :  Print  out  the  list  of  data  element  type  codes  (CT4)  and 

their  corresponding  meaning  (from  the  OHMIS  vocabulary 
word/phrase  data  base)  that  are  on  the  P52  list.  Ask  the 
user  to  identify  which  are  to  be  treated  as  secondary  base 
line  entries,  i.e.,  ask  the  user  for  El-n.  The  user  may 
enter  the  word  'ALL'.  For  each  data  element  type  that  the 
user  has  identified  as  a  secondary  base  line  entry, 
replace  the  ‘ N '  in  the  base  line  information  field  for  the 
data  element  type  with  a  code,  e.g.,  'S',  to  indicate 
this. 


P56:  GO  TO  P5  of  Step  F3B-4. 
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P57:  GO  TO  PI  of  Step  F3B-6. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


\ 

i 

1 

* 

1 

i 

\ 


i 


None 
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Identify  the  sequence  number  and  baseline  information  for  each  data 
element  type  on  the  form  being  entered  (and  for  all  previous  entries 
of  the  same  data  element  typed),  when  the  form  being  entered  contains 
data  that  is  not  the  most  recently  obtained,  i.e.,  when  the  forms  of 
this  form  type  and  for  this  forms  unit(s)  (e.g.,  employee)  have  been 
entered  onto  the  OHMIS  data  base  out  of  date  order.  When  the  forms  of 
a  given  type  and  for  a  given  forms  unit  are  entered  onto  the  OHMIS 
data  base  out  of  order  (i.e.,  not  in  the  order  that  the  data  was 
obtained),  it  is  possible  that  the  sequence  numbers  and  the  baseline 
information  on  the  data  element  types  for  all  previously  entered  forms 
are  of  this  type  and  for  this  forms  unit  are  also  out  of  order. 
Therefore,  this  step  puts  the  forms  in  proper  order  and  then  reviews 
all  previously  entered  forms  of  the  same  type  and  forms  unit  and  makes 
corrections  in  the  sequence  number  and  baseline  information. 

It  should  be  noted  that  this  same  process  (i.e..  Step  6  of  Function 
3B)  of  reordering  the  forms  (i.e.,  reassigning  previous  completed 
form  identifiers  (ID  18))  and  reassigning  sequence  numbers  is  required 
whenever  an  entire  set  of  completed  forms  data  (DS14)  is  deleted  by 
the  user  (Menu  Selection  Sequence  3.2),  unless  the  form  being  deleted 
is  a  one-time  form. 

PREVIOUS  STEP:  Step  F38-6  follows  P57  of  Step  F38-5. 

INPUTS  (R  -  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  retained  in  PI  of 

Step  F3B-1. 

R2:  The  temporary  list  consisting  of  the  pairs  of  IDl8s 

and  dates  (and  possibly  time  information,  i.e.,  hour, 
minute,  second)  for  the  form  ( I D 1 8 )  which  is  being 
entered  and  for  all  previous  forms  that  have  been 
entered  on  the  OHMIS  data  base  for  this  form  type 
(CT9)  and  forms  unit(s),  e.g.,  employee.  From  the 
P13  list  from  Step  F3B-5. 

R3:  The  temporary  list  of  forms  subpart  identifiers 

(ID17)  on  the  form  being  entered  (i.e.,  the  DS14  data 
for  the  I Dl 8  from  Rl)  that  have  unfilled  sequence 
numbers.  From  the  P2  list  from  Step  F3B-5. 

R4:  The  form  type  (CT9)  and  forms  unit(s)  for  the  type  of 

form  being  entered.  Retained  in  P3  of  Step  F3B-5. 

DS1U:  Forms  description  data. 

DS11:  Forms  subpart  data. 
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DS 14 :  Completed  forme  data. 

DL23:  Current  forms  list. 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  'program  logic 
loop) ) : 

PI:  Put  the  pairs  of  ID18s  and  dates  from  R2  in  ascending 

order  by  date,  i.e.,  so  that  each  date  is  equal  to  or 
later  than  the  previous  date.  (If  the  list  contains 
hours,  minutes,  seconds,  etc.,  put  the  1018s  in  ascending 
order  within  each  date  by  these  hours,  minutes,  seconds, 
etc.)  This  temporary  list  is  called  the  PI  list. 

P2:  Identify  the  first  ID18  on  the  PI  list,  i.e.,  the  ID18 

with  the  earliest  date.  Locate  the  DS 14  data  that 
corresponds  to  this  1018. 

P3:  Change  the  previous  1018  on  the  set  of  DS14  data  from  P2 

(i.e.,  not  the  1018  that  identifies  this  set  of  DS14 
data)  to  read  as  a  blank,  i.e.,  there  is  no  previous  ID18. 

P4:  Remove  the  first  1018  from  the  PI  list.  This  is  now  a  new 

list  called  the  P4  list.  (Do  not  erase  the  P2  list.) 

P5:  Identify  the  last  (latest)  1018  on  the  P2  list.  Replace 

the  1018  on  the  0123  list  (i.e.,  the  1018  for  the  latest 

form  for  the  type  of  form  (CT9)  and  forms  unit(s)  being 

entered  as  identified  in  R4)  with  this  last  ID18  on  the  P2 

list. 

FN1 :  FOR  each  ID18  on  the  P4  list: 

Ph;  Locate  the  DS 1 4  data  corresponding  to  this  1018. 

P7:  Identify  the  1018  on  the  P4  list  that  immediately  precedes 

the  I Dl 8  for  this  iteration  of  FN1 . 

P8:  Replace  the  previous  1018  on  the  DS14  data  identified  in 

P6  (i.e.,  not  the  1018  that  identifies  this  set  of  DS14 
data)  with  the  1018  identified  in  P7. 

P9:  NEXT  FNl;  end  of  FNl,  e~ase  the  P4  list  and  GO  TO  P10. 

P10:  Locate  the  0S14  data  with  the  1018  from  Rl;  locate  the 

DGlu  data  with  the  forms  specification  identifier  (ID16) 
on  this  DS14  data. 

FN2:  FOR  each  1017  on  the  R3  list,  i.e.,  each  form  subpart  on 

the  form  being  entered  for  which  there  are  unfilled 
sequence  numbers: 
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Pll:  Locate  the  DS11  data  for  this  ID17. 

FN2.1:  FOR  each  of  the  up  to  six  data  element  type  codes  (CT4) 
on  the  DS11  data  for  Pll  (i.e.,  this  iteration  from  FNl): 

P12:  Store  the  value  '1'. 

FN2.1.1:  FOR  each  of  the  1018s  on  the  P2  list: 

P13:  Is  this  ID18  (i.e.,  the  one  for  this  iteration  of  FN2.1.1) 

the  same  as  the  ID18  from  Rl,  i.e.,  the  1018  for  the  new 
form  being  entered?  Yes  =  P 14 ;  No  =  P22 

P14:  Locate  the  field  on  the  DS14  data  from  P10  containing  the 

data  element  type  in  this  iteration  of  FN2.1.  Place  the 
value  in  P12  in  the  sequence  number  field  for  this  data 
element  type. 

P15:  Add  '1'  to  the  value  in  P2. 

P16:  Is  the  baseline  information  field  for  the  data  element 

type  code  for  this  iteration  of  FN2.1  (as  identified  in 
P 1 4 )  filled  with  an  'X'  (not  baseline  type  of 
information)?  Yes  =  P46;  No  =  P17 

P17:  Was  the  sequence  number  added  for  this  data  element  type 

in  P14  a  T?  Yes  =  P18;  No  =  P20 

P18:  Place  an  '0'  (original  baseline)  in  the  baseline 

information  field  for  this  data  element  type. 

P 19 :  GO  TO  P46 . 

P20:  Place  a  'N1  (not  a  baseline  entry)  in  the  baseline 

information  field  for  this  data  element  type. 

P21 :  GO  TO  P4o . 

P22:  Locate  the  DS14  data  corresponding  to  the  1018  for  this 

iteration  of  FN 2.1.1.  Locate  the  DS10  data  corresponding 
to  the  forms  specification  identifier  (1016)  on  this  DS 1 4 
data . 

P23:  Is  the  1016  on  the  DS 1 4  data  for  the  form  being  entered 

(from  P10)  the  same  as  the  1016  on  the  DS 1 4  data  located 
in  P22,  i.e.,  the  DS14  data  for  this  iteration  of  FN 2.1.1? 
Yes  (i.e.,  it  is  certain  that  there  is  a  field  for  the 
data  element  type  in  this  iteration  of  FN2.1  on  the  form 
(0314  data)  for  this  iteration  of  FN 2 .1.1)  =  P24;  No  =  P26 

r.'4:  Jsinq  the  DS  1 1  data  from  Pll,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FN2.1. 
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P25 :  GO  TO  P37. 

P26 :  Identify  each  of  the  I D1 7 s  on  the  US 10  data  located  in  P22 

(i.e.,  the  forms  subpart  in  the  form  specification 
corresponding  to  the  set  of  DS 14  data  in  this  iteration  of 
FN 2.1.1).  Put  on  a  temporary  list  called  the  P26  list. 

FN2. 1.1.1:  FOR  each  ID1 7  on  the  P26  list: 

P27:  Locate  the  DS11  data  for  this  1017. 

P28:  Comparing  the  information  on  the  DS11  data  from  P27  with 

the  DS11  data  from  Pll,  do  the  two  sets  of  forms  subpart 
data  both  refer  to  the  same  exact  forms  unit  (or 
combination  of  forms  units)  on  their  respective  DS14  data? 
Yes  =  P29;  No  =  P36 

P29:  Is  the  ID17  for  this  iteration  of  FN2. 1.1.1  the  same  as 

the  1017  for  this  iteration  of  FN2?  Yes  (i.e.,  it  is 
certain  that  there  is  a  field  for  the  data  element  type 
for  this  iteration  of  FN2.1  on  the  DS14  data  for  this 
iteration  of  FN2.1.1)  =  P30;  No  =  FN2.1.1.1.1  (P32) 

P30:  Using  the  DS 1 1  data  from  P27,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FN 2.1  on  the  DS 14 
data  corresponding  to  the  ID18  for  this  iteration  of 
FN2.1.1. 

P 31 '  GO  TO  P 37  . 

FN2.1. 1.1.1:  FOR  each  of  the  up  to  six  data  element  types  on 
the  0S11  data  from  P27  (i.e.,  for  this  iteration  of 
FN2 .1.1.1): 

P32:  Is  this  the  same  data  element  type  as  the  data  element 

type  in  this  iteration  of  FN2 . ,  ?  Yes  (i.e.,  it  is  certain 
that  there  is  a  field  for  the  data  element  type  in  this 
iteration  of  FN2.1  on  the  US  1 4  data  for  this  iteration  of 
FN2.1.1)  =  P33 ;  No  =  P3b 

P3I,:  Locate  the  field  for  the  data  element  type  in  this 

iteration  of  FN2.1  for  the  0314  data  from  this  iteration 
of  FN2.1.1,  i.e.,  locate  Lee  field  in  which  the  data 
element  type  in  this  iteration  of  FN2.1.1.1.1  was  reached. 

P34:  GO  TO  P37. 

P35 :_  NEXT  FN2. 1.1.1;  end  of  FN2.1.1.1.1.  GO  TO  ‘>35. 

NEXT  FN2. 1.1.1;  end  of  FN2.I.I.1,  GO  iO  P4b. 


P3c: 
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P37:  Flag  the  field  on  the  DS14  data  for  this  iteration  of 

FN2.1.1  that  is  the  space  for  the  data  element  type  in 
this  iteration  of  FN2.1,  i.e.,  flag  the  field  identified 
in  P24 ,  P30 ,  or  P33. 

P3d:  Is  there  a  value  entered  on  the  DS 14  data  for  this 

iteration  of  FN2.1.1  (i.e.,  the  DS14  data  located  in  P22) 
in  the  field  flagged  in  P37,  i.e.,  does  this  form  contain 
any  value  for  the  data  element  type  in  this  iteration  of 
FN2.1?  Yes  =  P39;  No  =  P46 

P39:  Place  the  value  in  P12  as  the  new  sequence  number  for  the 

data  element  type  in  this  iteration  of  FN2.1  on  the  form 
(DS14  data)  for  this  iteration  of  FN2.1.1,  i.e.,  the 
sequence  number  for  the  data  element  type  flagged  in  P37. 

P40:  Add  the  '1*  to  the  value  stored  in  P12. 

P41:  Is  the  baseline  information  field  for  the  data  element 

type  flagged  in  P37  (i.e.,  the  data  element  type  for  this 
iteration  of  FN2.1  as  it  is  located  on  the  form  (DS14 
data)  for  this  iteration  of  FN2.1.1)  a  'no  baseline 
information'  type  of  data  element  type,  i.e.,  is  this 
field  filled  with  an  'X'?  Yes  =  P47;  No  -  P 42 

P42:  Was  the  sequence  number  added  for  this  data  element  type 

in  P39  a  *1'?  Yes  =  P43;  No  =  P45 

P43:  Place  an  'O'  (original  baseline)  in  the  baseline 

information  field  for  this  data  element  type. 

P44 :  GO  TO  P4b. 

P45:  Place  a  *  N '  (not  a  baseline  entry)  in  the  baseline 

information  field  for  this  data  element  type. 

P 46 :  NEXT  FN2.1.1;  end  of  FN2.1.1,  GO  TO  P47. 

P47;  NEXT  FN2.1;  end  of  FN2.1,  GO  TO  P48. 

P48:  NEXT  FN2 ;  end  of  FN2 ,  GO  TO  P49. 

P49 :  GO  TO  P52  of  Step  F3B-5. 


OUTPUTS  AND  GENERATION  SETS:  None 
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Identify  the  sequence  numbers  and  baseline  information  for  each 
missing  data  element  type  on  the  form  being  entered  (and  for  all 
previous  and  subsequent  entries  of  the  same  data  element  type),  when 
the  form  being  entered  is  a  Missing  Data  Element  Type  Form. 

The  data  element  type  that  is  missing  from  an  OHMIS  form  is  a  data 
element  type  for  which  the  value  for  the  data  element  type  was  not 
entered  on  the  OHMIS  data  base  at  the  time  that  the  form  containing 
the  data  element  type  was  entered  onto  the  OHMIS  data  base.  When 
entering  these  missing  data  elements  the  sequence  number  for  the  value 
for  the  data  element  type  depends  on  what  the  sequence  number  for  that 
data  element  type  was  on  the  form  previously  entered  containing  that 
data  element  type  that  was  for  the  same  form  type  and  for  the  same 
forms  unit(s)  (e.g.,  employee)  as  the  form  on  to  which  the  missing 
data  element  type  is  being  entered.  Therefore,  to  locate  the  sequence 
number  and  baseline  information  for  a  missing  data  element  type  it  is 
necessary  to  searcn  through  the  previously  entered  data  for  the  same 
forms  type/forms  unit.  This  is  similar  to  the  process  of  assigning 
sequence  numbers  to  new  (not  previously  missing)  data  element  type. 
However,  for  entries  of  missing  data  element  types  there  may  also  have 
been  subsequent  entries  of  data  onto  the  OHMIS  data  base,  i . e - , 
after  tne  form  containing  the  field  for  the  missing  data  element 
type  was  entered,  as  well  as  previous  entries.  This  means  that  the 
process  of  assigning  sequence  numbers/baseline  information  for  missing 
data  element  types  includes  a  revision  of  all  of  the  sequence  numbers 
and  baseline  information  fields  for  the  same  missing  data  element  type 
on  those  forms  for  the  same  forms  type/forms  unit(s)  entered  after  the 
form  containing  the  field  for  the  missing  data  element  type  was 
en  tered . 

The  process  described  here  for  entering  missing  data  element  types 
from  a  Missing  Data  Element  Type  Form  is  the  same  as  that  required 
when  adding  an  individual  missing  data  element  type,  i.e..  Menu 
Selection  Sequence  3.5,  except  that  that  process  is  only  to  enter  one 
missing  data  element  type  (equivalent  to  one  iteration  of  FN1,  i.e., 
one  missing  data  element  information  identifier  (1021))  on  a  completed 
form  data  set  (DS14)  identified  by  the  user. 

Similarly,  if  the  user  elects  to  change  a  value  for  a  previously 
entered  form  by  deleting  the  value,  that  part  of  the  process  of 
assigning  sequence  numbers  to  missing  data  element  types  that  involves 
revising  the  subsequent  entries  of  this  data  element  type  (i.e.,  the 
process  beginning  with  P60  in  Step  F3B- 7 )  must  be  conducted.  (Changes 
to  previously  entered  data  on  an  OHMIS  form  are  made  using  Menu 
Selection  Sequence  3.3.) 

PREVIOUS  STEP:  Step  F3B-7  follows  P13  of  Step  F3B-1. 

INPUTS  (S  =  Selections;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

H  =  Retrieval): 

Menu  Selectio n  and _ I nput  Sequence : 
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El-n:  Values  for  each  of  the  data  element  types  on  the 

particular  Missing  Data  Element  corm  being  entered  on 
to  the  OHMIS  data  base 

Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  retained  in  PI  of 

Step  F3B-1,  i.e.,  for  the  form  being  entered  in  this 
execution  of  Function  3B 

DSll):  Forms  description  data 

DS11:  Forms  subpart  data 

DS14;  Completed  form  data 

DS19:  Missing  data  element  information 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 

DL23:  Current  forms  list 

DL25:  Missing  data  element  list 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Locate  the  DS22  data  corresponding  to  the  1D18  from  Rl. 

FN1:  FOR  each  of  the  missing  data  element  type  information 

identifiers  (ID21)  on  the  DS22  data  from  PI: 

P2:  Locate  the  DS19  data  corresponding  to  the  ID21 .  Use  this 

data  to  identify  the  data  element  type  that  is  missing  and 
is  to  have  been  entered  on  the  Missing  Data  Element  Type 
Form  being  entered  in  this  execution  of  F3B;  also  use  this 
DS19  data  to  conduct  the  edits  on  the  entries  for  the 
values  of  the  data  element  type  entered  during  F3B  and  to 
determine  the  location  where  the  entries  are  to  be  stored 
(using  the  forms  description  data  (DS10)  and  the  forms 
subpart  data  (DSll)  referenced  in  the  DS19  data). 

P3:  Ask  the  user  for  El-n,  i.e.,  value  for  the  data  element 

type  that  is  on  the  DS19  data  for  this  iteration  of  FNl 
(i.e.,  the  data  element  type  correspond ing  to  this  ID21). 
In  other  words,  ask  the  user  to  enter  one  of  the  values  on 
the  completed  Missing  Data  Element  Type  Form. 

P 4 :  Did  the  user  provide  a  value  for  El-n  in  P3  that  passed 

the  edits  checks?  Yes  =  P 7 ;  No  =  P5 
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Erase  the  1018  from  R1  for  the  DS19  data  located  in  P2 
(i.e.,  the  1018  indicating  on  which  Missing  Data  Element 
Type  Form  the  value  for  the  missing  data  element  type 
on  this  OS 1 9  data  is  to  be  collected).  Do  not  erase  the 
entire  DS19  data.  (Note:  By  removing  the  1018  from  the 
0S19  data,  the  data  base  indicates  that  this  missing  data 
element  type  is  no  longer  being  collected  on  a  Missing 
Data  Element  Type  Form  and  can,  therefore,  be  put  on  any 
new  Missing  Data  Element  Type  Form  that  is  generated  in 
F3A.)  Also,  erase  the  1021  for  this  iteration  of  FNl  from 
the  DS22  data  located  in  PI,  but  do  not  erase  the  entire 
0S22  data.  (Note:  This  is  done  in  order  to  stop  the 
program  from  attempting  to  evaluate  allowable  limits  for 
this  missing  data  element  type;  no  allowable  limits 
evaluations  should  be  conducted  at  this  time  for  this 
missing  data  element  type  because  the  value  for  the 
missing  data  element  type  was  not  entered.) 

60  TO  P93 . 

Does  the  DS19  data  from  P2  indicate  that  the  data  element 
type  being  entered  (i.e.,  the  data  element  type  covered  by 
the  data  from  P2)  is  to  be  stored  on  the  0HMIS  data  base 
in  the  same  way  that  data  from  0HMIS  forms  are  stored, 
i.e.,  is  the  missing  data  element  type  missing  from  a 
partially  completed  0HMIS  form  rather  than  missing  from 
data  entered  from  an  External  Data  Source?  The 
determination  of  whether  the  missing  data  element  type  is 
missing  from  an  0HM1S  form  is  shown  by  whether  or  not 
there  is  a  completed  form  identifier  (ID18)  on  the  DS19 
data  for  the  missing  data  element  type  indicating  from 
what  previously  partially  completed  form  ( DS 14  data)  the 
data  element  type  being  entered  is  missing.  Yes  =  P12;  No 
=  P8 


Use  the  DS19  data  from  P2  to  determine  the  storage 
location  of  the  data  element  type  covered  by  the  DS19  data 
for  this  iteration  of  FNl. 

Store  the  El-n  value  entered  in  P3  on  the  OHMIS  data  base 
in  the  location  determined  in  P8. 


Erase  the  1021  from  this  iteration  of  FNl  from  the  DL25 
list.  Erase  the  entire  DS19  data  located  in  P2.  Erase 
the  ID21  from  this  iteration  of  FNl  from  the  DS22  data 
from  PI  (Note:  The  ID21  is  erased  from  the  DS22  data  in 
order  to  stop  and  allow  the  limits  evaluation  for  this 
data  element  type;  only  data  element  types  entered  and 
stored  on  OHMIS  forms  are  given  an  automatic  allowable 
limits  evaluation.) 
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Pll :  GO  TO  P93 . 

P12:  Determine  where  the  value  for  the  data  element  type 

entered  in  P3  ( i . e . ,  El-n)  is  to  be  stored.  To  do  this, 
use  the  DS19  data  from  P2  (i.e.,  the  DS19  data  for  the 
missing  data  element  type  being  entered)  to  identify 
the  completed  form  identifier  (ID18)  and  the  forms  subpart 
identifier  (ID17)  that  indicate  where  (on  what  completed 
form  data  ( DS 14 ) )  the  data  element  type  is  to  be  stored. 
Then  locate  the  DS10  data  that  corresponds  to  the  forms 
specification  identifier  (ID16)  on  this  DS14  data.  This 
DS10  da, a  describes  the  format  of  the  form  onto  which  the 
missing  data  element  type  is  to  be  entered  and  gives  the 
location  of  the  forms  subpart  on  the  form.  Then  review 
the  DS11  data  for  the  forms  subpart  identifier  (ID17)  on 
which  the  missing  data  element  type  is  stored  to  locate 
the  particular  field  (the  particular  data  element  type  in 
this  forms  subpart)  in  which  the  missing  data  element  type 
is  to  be  stored. 

P13:  Enter  the  value  for  the  missing  data  element  type  (i.e., 

El-n)  onto  the  DS14  data  identified  in  P4. 

P14:  Tell  the  user  that  the  program  is  now  looking  for  the  Data 

Element  Sequence  Numbers  and  baseline  information  for  the 
missing  data  element  type  just  entered. 

P15:  Use  the  DS10  data  identified  in  P12,  i.e.,  the  DS10  data 

that  gives  the  forms  specification  (format)  for  the 
completed  form  data  (DS14)  onto  which  the  missing  data 
element  type  has  been  entered,  determine  whether  this  is  a 
one-time  form  (i.e.,  all  data  element  types  on  this  form 
are  non-changing  data  element  types).  Yes  =  P16;  No  =  P18 

P16:  Place  an  'X'  (not  a  multiple  entry  and  therefore  no 

sequence  number  or  baseline  information  is  needed)  in  both 
the  sequence  number  and  baseline  information  field  on  the 
DS14  data  identified  in  P12  for  the  data  element  type 
corresponding  to  the  missing  data  element  type  entered  in 
P3,  i.e.,  the  missing  data  element  for  this  iteration  of 
FNl . 

P17 :  GO  TO  P93 . 

P18:  Using  the  DS10  data  identified  in  P 12 ,  determine  if  this 

is  a  'no  baseline  information'  form,  i.e.,  none  of  the 
data  element  types  on  the  DS 1 4  data  containing  the  missing 
data  element  type  for  this  iteration  of  FNl  have  baseline 
information.  Yes  =  P19;  No  =  P20 
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P19:  Place  an  'X'  (no  baseline  information)  in  the  baseline 

information  field  on  the  DS14  data  identified  in  P12  for 
the  data  element  type  corresponding  to  the  missing  data 
element  type  entered  in  P3,  i.e.,  from  this  iteration  of 
FNl. 

P20:  Identify  the  DS11  data  from  the  forms  subpart  (1017)  that 

was  determined  in  P 12  to  be  the  storage  location  of  the 
missing  data  element  type  being  entered. 

P21:  Using  the  DS11  data  from  P15,  determine  if  the  missing 

data  element  type  is  a  non-changing  data  element  type. 

Yes  =  P16;  No  =  P22 

P22:  Examine  the  DS14  data  identified  in  P12,  i.e.,  the 

completed  form  data  that  contains  the  missing  data  element 
type  being  entered.  Does  this  DS14  data  contain  a 
previous  ID18,  i.e.,  the  ID18  identifying  the  previous 
set  of  DS14  data  that  is  for  the  same  forms  type  and  forms 
unit(s)?  (This  is  not  the  same  as  the  ID18  that 
identifies  the  0S14  data  from  P12.)  Yes  =  P29;  No  =  P23 

P23:  Assign  the  missing  data  element  type  for  this  iteration  of 

FNl  the  sequence  number  of  ‘l*.  Store  this  sequence 
number  in  the  sequence  number  field  for  the  missing  data 
element  type  for  which  the  storage  location  was  identified 
in  P12 . 

P24:  Using  the  DS11  data  from  P 15  (i.e.,  the  0S11  data 

corresponding  to  the  missing  data  element  type  being 
entered),  determine  if  the  data  element  type  has  baseline 
information.  Yes  =  P25;  No  =  P27 

P25 :  Assign  the  code  'O'  (original  baseline)  to  the  baseline 

information  field  for  the  missing  data  element  type.  This 
field  corresponds  to  the  field  for  the  missing  data 
element  type  identified  in  P12. 

P26 :  GU  TO  P60. 

P27 :  Assign  the  code  'X'  (data  element  type  is  not  a  baseline 

type  of  data)  to  the  baseline  information  field  for  the 
missing  data  element  type. 

P28:  GO  TO  P60. 

P29:  Identify  this  previous  ID18  on  the  DS14  data  located  in 

P 12 . 

P30:  Put  the  1018  from  P29  at  the  top  of  (first  on)  a  temporary 

list,  called  the  P30  list.  The  order  of  the  ID18s  on  this 
list  is  important. 
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P31 :  Locate  the  DS14  data  from  the  1018  that  was  last  entered 

(entered  at  the  bottom  of)  the  P30  list.  Locate  the  DS10 
data  from  the  forms  specification  identifier  (1D16)  on 
this  DS14  data. 

P32:  Does  the  DS14  data  from  P 31  contain  a  previous  1018  (not 

the  1018  that  identifies  this  set  of  DS14  data)?  Yes  = 
P33;  No  =  FN1.1  (P35) 

P33:  Identify  this  previous  ID18  and  put  it  at  the  bottom  (end) 

of  the  P30  list. 

P34:  GO  TO  P31. 

FN1.1:  FOR  each  1018  on  the  P30  list: 

P 35 :  Locate  the  DS14  data  for  this  1018.  Locate  the  DS10  data 

for  the  1016  that  is  in  this  DS14  data. 

P36:  Is  the  1016  for  the  uS 10  data  located  in  P35  the  same  as 

the  1016  from  the  DS10  data  identified  in  P12,  i.e.,  does 
this  previous  DS14  data  have  the  same  form  specification 
as  the  form  onto  which  the  missing  data  element  type  was 
entered?  Yes  (i.e.,  it  is  certain  that  there  is  a  field 
for  the  missing  data  element  type  for  this  iteration  of 
FNl  on  the  previous  DS14  data  for  this  iteration  of  FNl.l) 
=  P37 ;  No  =  P39 

P37:  Using  the  DS11  data  from  P20,  locate  the  field  for  the 

missing  data  element  type  in  this  iteration  of  FNl. 

P38:  GO  TO  P50. 

P39:  Identify  each  of  the  I D17 s  on  the  DS10  data  located  in  P35 

(i.e.,  the  forms  subpart  in  the  forms  specification 
corresponding  to  the  previous  set  of  DS14  data  for  this 
iteration  of  FNl.l).  Put  on  a  temporary  list  called  the 
P39  list. 

FNl .1,1:  FOR  each  1017  on  the  P39  list: 

P40:  Locate  the  DSll  data  for  this  1017. 

P41:  Comparing  the  information  on  the  DSll  data  from  P40  with 

the  DSll  data  from  P20,  did  the  two  sets  of  forms  subpart 
data  both  refer  to  the  same  exact  forms  unit  (or 
combination  of  forms  units)  on  their  respective  DS14  data? 
Yes  =  P42;  No  =  P49 

P42:  Is  the  ID17  for  this  iteration  of  FNl. 1.1  (as  identified 

in  P4U)  the  same  as  the  1017  for  the  DSll  data  identified 
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in  P20,  i.e.,  the  same  as  the  forms  subpart  in  which  the 
missing  data  element  type  is  stored?  Yes  (i.e.,  it  is 
certain  that  there  is  a  field  for  the  missing  data  element 
type  from  this  iteration  from  FNl  on  the  previous  DS14 
data  from  this  iteration  of  FNl.l)  =  P43;  No  =  FNl. 1.1.1 
(P45 ) 

P43:  Using  the  DS11  data  from  P40,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FNl  on  this 
previous  DS14  data,  i.e.,  the  DS 14  data  corresponding  to 
the  1018  for  this  iteration  of  FNl.l. 

P44 :  GO  TO  P50. 

FNl. 1.1.1:  FOR  each  of  the  up  to  six  data  element  types  on  the 
DS11  data  from  P40  (i.e.,  for  this  iteration  of  FNl. 1.1): 

P45 :  Is  this  the  same  data  element  type  as  the  missing  data 

element  type  in  this  iteration  of  FNl?  Yes  (i.e.,  it  is 
certain  that  there  is  a  field  for  the  missing  data  element 
type  for  this  iteration  of  FNl  on  the  previous  DS14  data 
for  this  iteration  of  FNl.l)  =  P4b;  No  =  P48 

P46:  Locate  the  field  for  the  data  element  type  in  this 

iteration  of  FNl  for  this  DS14  data  (the  DS14  data 
corresponding  to  this  iteration  of  FNl.l),  i.e.,  the  field 
in  which  the  data  element  type  in  this  iteration  of 
FNl. 1.1.1  was  reached. 

P47 :  GO  TO  P50. 

P48:  NEXT  FNl. 1.1.1;  end  of  FNl.  1.1.1,  GO  TO  P49. 


P49:  NEXT  FNl. 1.1;  end  of  FNl. 1.1,  GO  TO  P59. 


P50:  Flag  the  field  on  the  previous  DS14  data  (i.e.,  the  DS14 

data  corresponding  to  the  ID18  for  this  iteration  of 
FNl.l)  that  is  the  space  for  the  data  element  typed  in 
this  iteration  of  FNl,  i.e.,  flag  the  field  identified  in 
P37 ,  P43 ,  or  P46. 

P51 :  Is  there  a  value  entered  on  the  previous  DS 14  data  from 

P38  in  the  field  flagged  in  P50?  Yes  =  P52 ;  No  =  P59 

P52:  Locate  the  Data  Element  Sequence  Number  for  the  data 

element  type  flagged  in  P39  (in  the  sequence  number  field 
for  this  data  element  type  on  the  DS14  data  from  P24). 

Add  '1'  to  the  value  of  this  Data  Element  Sequence  Number. 
Place  this  new  Data  Element  Sequence  Number  on  the  DS 1 4 
data  from  P12  (i.e.,  the  DS14  data  onto  which  the  missing 
data  element  type  was  entered)  for  the  Data  Element  Type 
Sequence  Number  of  the  data  element  type  in  this  iteration 
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of  FNl.  Retain  this  sequence  number  throughout  this 
iteration  of  FNl. 

P53:  Is  the  baseline  information  field  for  the  missing  data 

element  type  on  the  DS14  data  from  this  iteration  of  FNl.l 
a  'no  baseline  information'  type  of  data  element  type, 
i.e.,  is  the  baseline  information  field  for  this  data 
element  type  on  the  DS14  data  from  P12  already  filled  with 
an  'X'?  Yes  =  P60 ;  No  =  P54 

P54:  Ask  the  user  whether  the  missing  data  element  type  just 

entered  is  to  be  a  'secondary  baseline'  entry.  Yes  =  P55; 
No  =  P57 

P55 :  Assign  a  'S'  (secondary  baseline  entry)  to  the  baseline 

information  field  for  the  missing  data  element  typed  in 
this  iteration  of  FNl,  i.e.,  on  the  baseline  information 

field  on  the  DS14  data  for  this  data  element  type  located 

in  P12 . 

P56 :  GO  TO  P60. 

P57 :  Assign  a  ' N '  (not  a  baseline  entry)  to  the  baseline 

information  field  for  the  missing  data  element  type  in 
this  iteration  of  FNl,  i.e.,  on  the  baseline  information 

field  on  the  0514  data  for  this  data  element  type  located 

in  P12. 

P58:  GO  TO  P60. 

P59 :  NEXT  FNl;  end  of  FNl.l,  GO  TO  P23. 

P60:  Locate  the  form  unit(s)  and  the  form  type  (CT9)  for  the 

form  (DS14  data)  onto  which  the  missing  data  element  type 
was  entered  (i.e.,  this  information  is  on  the  DS 14  data 
identified  in  P12.  Retain  this  information  throughout 
this  iteration  of  FNl. 

P61 :  Is  the  I  Did  from  P 12  (i.e.,  the  I D 1 8  for  the  completed 

form  data  (DS14)  onto  which  the  missing  data  element  type 
has  been  entered/stored)  the  same  as  the  ID18  on  the  DL23 
list  for  the  form  unit(s)/form  type  identified  in  P60? 

That  is,  is  the  form  onto  which  the  missing  data  element 
type  was  entered/stored  the  latest  form  entered  onto  the 
OHMIS  data  base  (i.e.,  the  form  containing  the  most 
recently  collected  data)  for  this  type  of  form  and  for 
this  forms  unit(s)?  Yes  =  P93;  No  (i.e.,  it  is  necessary 
to  check  and  possibly  change  the  Data  Element  Sequence 
Number  and  baseline  information  fields  on  the  data  element 
types  entered  subsequent  to  the  missing  data  element  type) 
=  P62 
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P62 :  Using  the  DL23  list,  identify  the  latest  ID18  for  the 

forms  unit( s)/forms  type  identified  in  P60. 

P63:  Put  the  ID18  from  P62  on  the  top  of  (first  on)  a  temporary 

list  called  the  P63  list.  The  order  of  the  1D18s  on  the 
P63  list  is  important. 

P64:  Locate  the  OS  14  data  for  the  1D18  last  entered  on  (entered 

at  the  bottom  of)  the  P63  list. 

P65 :  Locate  the  previous  1018  on  the  DS14  data  located  in  P64 

(not  the  one  identifying  the  set  of  0S14  data). 

P66:  Is  the  ID18  located  in  P65  the  same  as  the  ID18  from  P12, 

i.e.,  is  this  form  onto  which  the  missing  data  element 
type  was  entered?  Yes  =  P69;  No  =  P67 

P67 :  Put  the  ID18  from  P 65  at  the  bottom  (end)  of  the  P63  list. 

P68:  GO  TO  P64. 

P69:  Reverse  the  order  of  the  IDISs  on  the  P63  list,  i.e.,  put 

them  in  order  of  increasingly  1 ater  dates  of  the  date  on 
which  the  data  on  the  form  was  obtained,  starting  with  the 
form  after  the  form  onto  which  the  missing  data  element 
type  for  this  iteration  of  FNl  was  entered.  This  is 
called  the  P69  list  and  the  IDISs  on  this  list  are 
referred  to  as  the  subsequent  IDl8s,  because  the  DS 1 4 
data  corresponding  to  these  1013s  was  obtained  subsequent 
to  the  date  that  the  data  on  the  form  for  which  the 
missing  data  element  was  entered  was  obtained. 

P7U:  Store  the  Data  Element  Sequence  Number  entered  for  the 

missing  data  element  type  being  entered  in  this  iteration 
of  FNl.  (This  value  is  obtained  from  P52.) 

FNl. 2:  FOR  each  I D 13  on  the  P69  list: 


P71:  Locate  the  DS14  data  for  this  ID18.  Locate  the  DS10  data 

corresponding  to  the  forms  specification  identifier  on 
this  DS14  data. 

P72:  Is  the  I U 16  on  the  DS14  data  from  P 12  (i.e.,  the  form  onto 

wnich  the  missing  data  element  type  was  entered)  the  same 
as  the  1016  identified  in  P71,  i.e.,  the  same  as  the  ID16 
cn  the  subsequent  DS14  data  if<>r  this  iteration  of 
FNl. 2)?  Yes  (i.e.,  it  is  certain  that  there  is  a  field 
for  a  data  element  that  is  the  same  as  the  missing  data 
element  type  for  this  iteration  of  FNl  on  the  subsequent 
DS14  data  for  this  iteration  of  FNl. 2)  -  P 73 ;  No  =  P75 


I  — 
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P 7 J :  Using  the  DS11  data  from  P71,  locate  the  field  for  the 

data  element  type  in  this  iteration  of  FNl. 

P 74 ;  GU  TO  P36. 

P 75 :  Identify  each  of  the  1017s  on  the  DS10  data  located  in  P71 

(i.e.,  the  forms  subpart  in  the  forms  specification  (DS10) 
corresponding  to  the  subsequent  DS 14  data  for  this 
iteration  of  FNl. 2.)  Put  on  a  temporary  list  called  P75 
list. 

FNl. 2.1:  FOR  each  1017  on  the  P75  list: 

P 76:  Locate  the  DS11  data  for  this  ID17. 

P77:  Canparing  the  information  on  the  DS11  data  from  P20  (i.e., 

the  forms  subpart  where  the  missing  data  element  for  tnis 
iteration  of  FNl  was  entered)  with  the  DS11  data  from  P76, 
do  the  two  sets  of  forms  subpart  data  both  refer  to  the 
same  exact  forms  unit  (or  combination  of  forms  units)  on 
their  respective  DS 1 4  data?  Yes  =  P78;  No  =  P85 

P 78 :  Is  the  1017  for  this  iteration  of  FNl. 2.1  the  same  as  the 

ID 1 7  for  P12  (i.e.,  the  1017  for  the  forms  subpart  on 
which  the  missing  data  element  type  in  this  iteration  of 
FNl  was  stored)?  Yes  (i.e.,  it  is  certain  that  there  is  a 
field  for  the  data  element  type  for  this  iteration  of  FNl 
on  the  subsequent  DS 14  data  for  this  iteration  of  FNl. 2.1) 
=  P 79 ;  No  =  FNl. 2. 1.1  (P81) 

P79:  Using  the  DS11  data  fi om  D7t>,  locate  the  field  for  the 

missing  data  element  type  in  this  iteration  of  FNl  on  this 
subsequent  DS 1 4  data,  i.e.,  on  the  DS14  data  corresponding 
to  the  1018  for  this  iteration  of  FNl. 2. 

P80  :  GU  TO  P8o. 

FNl. 2. 1.1:  FOP  each  of  the  up  to  six  data  element  types  on  the 
DS11  data  from  P76  (i.e.,  for  this  iteration  of  FNl. 2.1): 

P81:  Is  this  the  same  data  element  type  as  the  missing  data 

element  type  in  this  iteration  of  FNl?  Yes  (i.e.,  it  is 
certain  that  tnere  is  a  field  for  the  missing  data  element 
type  for  this  iteration  for  FNl  on  the  subsequent  DS 14 
data  for  this  iteration  of  FNl. 2)  =  P82;  No  =  P34 

PS2:  Locate  tne  field  for  the  missing  data  element  typed  in 

this  iteration  of  FNl  for  this  subsequent  OS  14  data  (the 
DS14  data  corresponding  to  the  1018  in  this  iteration  of 
FNi.2),  i.e.,  tne  field  in  which  the  data  element  type  in 
this  iteration  of  FNl. 2. 1.1  was  reached. 
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P83 :  GO  TO  P86. 

P84:  NEXT  FNl.2.1.1;  end  of  FNl.2.1.1,  GO  TO  P85. 

P85:  NEXT  FNl.2.1;  end  of  FNl.2.1,  GO  TO  P92. 

P86:  Flag  the  field  on  the  subsequent  DS 1 4  data  (i.e.,  the  DS14 

data  corresponding  to  the  1018  for  this  iteration  of 
FNl. 2)  that  is  the  space  for  the  same  data  element  type  as 

the  missing  data  element  type  in  this  iteration  of  FNl, 

i.e.,  the  flag  the  field  identified  in  P74,  P79,  or  P82. 

P87:  Is  there  a  value  entered  on  the  subsequent  DS14  data  from 

P71  in  the  field  flagged  in  P86?  Yes  =  P86;  No  =  P92 

P88:  Add  '1'  to  the  Data  Element  Sequence  Number  value  stored 

in  P70. 

P89:  Assign  the  Data  Element  Sequence  Number  stored  in  P70  to 

tne  sequence  number  field  on  the  subsequent  DS 14  data  for 
this  iteration  of  FNl. 2  for  the  data  element  typed  in  this 
iteration  of  FNl,  i.e.,  to  the  Data  Element  Sequence 
Number  field  for  the  data  element  type  whose  location  was 
flagged  in  P86. 

P9u:  Identify  the  baseline  information  field  for  the  data 

element  type  in  this  iteration  of  FNl  on  this  subsequent 
DS14  data  (i.e.,  the  baseline  information  field 
corresponding  to  the  field  on  the  DS14  data  located  in  P71 
for  the  data  element  type  whose  field  was  flagged  in  P86). 
Does  this  field  contain  a  'O'  (original  baseline)?  Yes  = 
P’  ;  No  =  P92 

P 91 :  change  the  baseline  information  field  identified  in  P90  to 

read  ‘N’  (not  a  baseline  entry). 

P92j _ NEXT  FNl. 2;  end  of  FNl. 2,  GO  Tu  P93. 

P93: _ NEXT  FNl;  end  of  FNl,  GO  TO  P94. 

P94:  GO  TO  Pi  of  Step  F3B-14. 

OUTPUTS  kNU  oLNEKAT IONS  OF  DATA  SETS:  None 
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This  step  begins  the  process  of  evaluating  allowable  limits  for  the 
data  being  entered  in  this  execution  of  Function  F3B. 

In  this  step,  tne  program  determines  whether  there  are  any  allowable 
limits  specifications  for  the  forms  specif ication  being  entered  in 
this  execution  of  Function  F3B  that  apply  to  the  form-as-a-wnol e. 

If  there  are,  the  program  determines  whether  there  is  a  default 
allowable  limit  for  this  specification. 

In  OHMIS  allowable  limits  (or  unallowable  limits)  can  be  set  for  a 
given  data  element  type  (e.g.,  a  single  medical  test  result  for  a 
given  employee)  or  for  entering  an  entire  class  or  set  of  data 
elements  such  as  data  on  a  hazardous  substance  spill  or  other 
incident.  Classes  of  data  are  identified  by  the  forms  specification 
( I D 16 )  of  the  form  from  which  the  class  of  data  is  entered;  that  is, 
the  user  is  said  to  be  entering  an  entire  class  of  data  when  he/she 
enters  data  from  a  specification  of  a  form  of  the  type  that  covers 
that  type  of  data.  For  example,  when  entering  data  onto  the  UHM1S 
data  base  from  a  form  such  as  a  report  used  to  record  hazardous 
substance  spills,  the  user  is  said  to  be  entering  data  on  the 
hazardous  substance  spill  class  of  data.  In  Step  F3B-8,  the  program 
checks  to  determine  if  there  are  any  allowable  limits  for  entering  the 
class  of  data  ( i . e . ,  the  data  for  the  particular  form  type  (CT9)  and 
version  (1016))  being  entered  in  this  execution  of  Function  F3B.  For 
example,  there  may  be  an  allowable  limit  on  how  many  hazardous  spills 
can  take  ^lace  for  a  given  facility  before  a  given  requirement 
(action)  must  be  initiated.  This  type  of  allowable  limit  would  be 
shown  in  the  form  of  the  number  of  forms  of  the  type  covering 
hazardous  substance  spills  coming  from  a  given  facility  within  a  given 
time  span  before  a  requirement  should  be  triggered. 

Sane  allowable  limits  apply  only  in  a  given  circumstance;  in  the  above 
example,  an  allowable  limit  might  be  specified  for  hazardous  spills  in 
only  certain  facilities.  Other  allowable  limits  have  no  applicability 
specifications,  i.e.,  they  apply  in  all  circumstances .  These  are 
called  the  defaul t  allowable  limits.  Step  F3B-8  determines  whether 
the  allowable  ’imit  for  the  forms  specification  being  entered  is  a 
default  allowable  limit. 

PREVIOUS  STEP:  Step  F3B-3  follows  P6  of  Step  F3B-4. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Completed  form  identifier  (11)13)  retained  ■■  •  1 

Step  F3B-1,  i.e.,  the  1013  of  the  form  be  ' 

in  this  axe. rut  ion  of  Function  F  3r. 
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R2:  Next  available  allowable  limits  check  request 

identifier  (ID22) 

R3:  Current  date 

DS14:  Completed  forms  data 

0S17:  Allowable  limits  specification  data 

DL17:  List  of  allowable  limits  check  request  identifiers 
(1022)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (ID10) 

DL29:  List  of  active  (allowable  limits  specification) 

requirement  application  identifiers  (ID5)  by  forms 
specification  identifier  (ID16)  and  OHMIS  service 
area  (ID10) 

DL30:  List  of  active  default  (allowable  limits 

specification)  requirement  application  identifiers 
(ID5)  by  forms  specification  identifier  (ID16)  and 
OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  *  For  Next  (program  logic 
loop)) : 

PI:  Tell  user  that  the  process  of  evaluating  allowable  limits 

for  the  data  on  the  form  just  entered  is  now  just 
beginning.  Locate  the  DS14  data  for  the  ID18  from  Rl. 
Locate  the  DS10  data  corresponding  to  the  forms 
specification  identifier  (ID16)  on  this  DS14  data.  Also, 
locate  the  OHMIS  service  area  identifier  (1010)  and  the 
previous  1018,  if  any,  that  on  this  DS14  data. 

P2:  Using  DL29,  determine  whether  there  are  any  allowable 

limits  specification  data  (DS17)  for  the  ID16  and  1010 
identified  in  PI,  i.e.,  whether  there  are  any  allowable 
limits  set  for  entering  this  type  of  form-as-a-whole. 

That  is,  determine  whether  are  any  allowable  limits  for 
entering  the  class  of  data  identified  by  the  forms 
specification  (ID16)  for  the  form  being  entered  in  this 
execution  of  Function  F3B.  Yes  =  P4;  No  =  P3 

P3:  GO  TO  PI  Step  F3B-11. 

P4:  Begin  generating  a  set  of  DS18  data  for  the 

form-as-a-whole.  Assign  the  ID22  from  R2;  the  1010 
identified  in  PI;  the  date  from  R3;  the  ID18  from  Rl  as 
the  first  1018,  i.e.,  the  1018  identifying  the  OSH  data 
from  PI  as  the  form  being  entered  in  this  execution  of 
Function  F3B;  and,  the  ID1S  from  the  previous  set  of 
OSH  data,  if  any,  from  PI.  Identify  this  set  of  DS18 
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data  as  a  forms -as -a-whole  type  of  allowable  limits 
evaluation  (i.e.,  assign  the  answer  of  '2').  Assign  the 
ID16  from  Pi  to  this  DS18  data  and  leave  the  forms  subpart 
identifier  (1017)  field  on  this  DS18  data  blank. 

P5:  Using  the  0S10  data  from  PI,  identify  the  up  to  nine  types 

of  forms  units  that  apply  to  the  form-as-a-whole  for  the 
form  being  entered  in  this  execution  of  Function  F3B. 

P6:  Obtain  the  values  (identifiers)  for  the  types  of  forms 

units  identified  in  P5  from  the  DS14  data  from  PI  and 
enter  these  values  onto  the  DS18  data  generated  in  P4. 

P7:  Add  the  1022  assigned  to  the  DS18  data  generated  in  P4  to 

the  0L17  list  for  the  1018  and  ID10  identified  in  Pi. 

P8:  Using  DL30,  determine  whether  there  is  only  a  default 

set  (or  a  default  series  of  sets)  of  DS17  data  for  the 
1016  and  ID10  identified  in  PI.  Yes  (i.e.,  there  is  only 
one  set  or  one  series  of  sets  of  allowable  limits  for  this 
1016  and  it  applies  in  all  cases)  =  PIO;  No  (i.e.,  there 
are  one  or  more  sets  of  allowable  limits  for  this  1D16  and 
ID10  and  each  is  to  be  used  (is  applicable)  in  only 
limited  cases;  it  is  therefore  necessary  to  determine 
which  set  or  series  of  sets  of  allowable  limits 
specifications  data  applies)  =  P9 

P9:  GO  TO  PI  of  Step  F3B-9. 

P10:  Using  DL30,  identify  the  requirement  application 

identifier  (105)  or  series  of  ID5s  that  are  the  default 
DS  data  sets  for  the  1016  from  PI.  Put  the  ID5s  on  a 
temporary  list  called  the  P10  list. 

FN1:  FOR  each  ID5  on  the  P10  list: 

Pll:  Is  this  the  first  105  on  the  P10  list?  Yes  *  P13;  No  = 

P12 . 

P12:  Begin  generating  a  new  set  of  DS18  data  as  described  in  P4 

through  P6.  This  DS18  data  is  referred  to  as  the  P12  DS18 

data.  Add  the  ID22  for  this  new  DS14  data  to  the  DL17 
list  for  the  ID18  and  ID10  identified  in  PI. 

P13:  Enter  the  105  from  this  iteration  of  FNl  on  the  DS18  data 

from  either  P4  (if  the  answer  to  Pll  was  'Yes')  or  P12  (if 

the  answer  to  Pll  was  'No'). 

P14:  Locate  the  0S14  data  for  the  105  for  this  iteration  of 

FNl. 
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P15:  Using  the  0S17  data  from  P14,  identify  which  of  the  up  to 

nine  forms  units  for  the  form  in  this  execution  of 
Function  F3B  (i.e.,  the  forms  units  identified  in  P6  and 
entered  on  the  DS18  data  from  P4  and  P12)  are  to  be  used 
to  evaluate  allowable  limits.  Enter  this  information  on 
the  DS18  data  from  either  P4  (if  the  answer  to  Pll  was 
'Yes')  or  P12  (if  the  answer  to  Pll  was  'No'). 

P16:  Using  the  DS17  data  from  P14,  identify  which  of  the  up  to 

nine  forms  units  from  P6  are  to  be  used  as  requirement 
implementation  units  should  a  match  be  found  with  the 
allowable  limits  specified  in  this  DS17  data.  Enter  this 
information  on  the  DS18  data  from  either  P4  (if  the  answer 
to  Pll  was  'Yes')  or  P12  (if  the  answer  to  Pll  was  'No'). 

P17:  NEXT  FNl ;  end  of  FNl,  GO  TO  P3. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS18:  Allowable  limits  check  request  data  (for  a 
form-as-a-whole) 


i 
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Identify  the  factors  that  determine  which  allowable  limits 
specifications  are  applicable  to  the  particular  type  of  form  being 
entered  in  this  execution  Function  F3B.  Obtain  the  values  for  these 
factors  from  the  current  OHMIS  data  base,  where  available,  and  store 
these  values.  (If  not  possible  to  obtain  all  of  these  values  from  the 
current  OHMIS  data  base,  it  may  be  necessary  to  conduct  an  allowable 
limits  check  (Function  F3C)  to  determine  which  allowable  limits  are 
applicable. ) 

PREVIOUS  STEP:  Step  F38-9  follows  P9  of  Step  F38-8. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Allowable  limits  check  request  data  (DS18)  generated 

in  P4  of  Step  F3B-8 

DS7:  Data  element  typed  information 

DS15:  Allowable  limits  applicability  factors  data 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Identify  the  forms  specification  identifier  (ID16)  and  the 

OHMIS  service  area  identifier  (ID10)  on  the  DS18  data  from 
Rl,  i.e.,  the  ID16  and  ID10  for  the  form  being  entered  in 
this  execution  of  Function  F3B. 

P2:  Locate  the  DS15  data  for  the  ID16  and  ID10  from  PI. 

P3:  Abstract  from  the  DS15  data  located  in  P2  the  up  to  five 

data  element  type  codes  (CT4)  for  the  allowable  limits 
applicability  factors  for  each  of  the  up  to  nine  forms 
units  for  the  form  being  entered  in  this  execution  of 
Function  F3B.  Enter  these  CT4  onto  the  DS18  data  from  Rl. 

FN1:  FOR  each  of  the  CT4  identified  in  P3,  i.e.,  each  of  the 

factors  that  determine  which  allowable  limits 
specifications  are  applicable  to  the  form  being  entered  in 
this  execution  of  Function  F3B: 

P4:  Use  the  DS7  data  to  determine  where/how  the  value  for  the 

data  element  type  in  this  iteration  of  FN1  is  stored. 
Determine  whether  there  is  a  currently  a  value  for  this 
data  element  type  (this  allowable  limits  applicability 
factor)  for  the  forms  unit  corresponding  to  this  factor  on 
the  form  being  entered  (as  identified  on  the  DS18  data 
from  Rl)  on  the  OHMIS  data  base.  Yes  (i.e.,  the  current 
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OHMIS  data  base  contains  the  value  for  one  of  the  data 
element  types  that  will  determine  which  allowable  limits 
specifications  are  applicable)  =  P5;  No  =  P6 

P5:  Enter  the  value  for  the  allowable  limits  applicability 

factor  (i.e.,  the  value  for  the  CT4  for  this  iteration  of 
FNl  located  in  P4)  on  the  DS18  data  from  Rl. 

P6:  NEXT  FNl ;  end  of  FNl,  GO  TO  P7. 

P7:  Review  the  0S18  data  from  Rl.  Do  alj_  of  the  allowable 

limits  applicability  factors  (i.e.,  the  CT4s  identified  in 
P3)  have  values  entered  on  the  DS18  data?  Yes  (i.e., 
there  is  information  available  on  the  DS18  data  from  Rl  to 
determine  which  allowable  limits  specifications  data  are 
applicable)  =  P9;  No  =  P8 

P8:  Do  some  of  the  allowable  limits  applicability  factors 

have  values  entered  on  the  DS18  data  from  Rl?  Yes  =  P10; 
No  (i.e.,  it  is  not  possible  to  determine  which  allowable 
limits  are  applicable)  =  Pll 

P9:  GO  TO  Pi  of  Step  F3B-10. 

P10:  GO  TO  P 19  of  Step  F3B-10. 

Pll:  GO  TO  PI  of  Step  F38-11. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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Determine  whether  there  are  any  allowable  limits  specifications 
applicable  to  the  form  being  entered  for  this  execution  of  Function 
F3B,  i.e.,  whether  there  are  specified  values  for  the  allowable  limits 
applicability  factors  for  the  type  and  version  of  form  being  entered 
that  match  the  values  for  these  factors  for  the  forms  unit(s)  on  the 
form  being  entered.  If  there  are  applicable  allowable  limits 
specifications,  store  the  information  on  the  identification  of  these 
specifications  on  the  allowable  limits  check  request  data  (DS18). 

PREVIOUS  STEP:  Step  F3B-10  follows  P9  of  Step  F3B-9. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 


Data  Retrievals: 

Rl:  Allowable  limits  check  request  data  (DS18)  generated 

in  P4  of  Step  F3B-8 

R2:  List  of  data  element  type  codes  (CT4)  that  are  the 

allowable  limits  applicability  factors  (i.e.,  the 
factors  that  determine  which  allowable  limits 
specifications  are  applicable)  for  the  form  being 
entered  in  this  execution  of  Function  F3B.  This  list 
was  obtained  in  P3  of  Step  F3B-9 

DS16:  Allowable  limits  applicability  values  data 

DS17:  Allowable  limits  specification  data 

DL16:  List  of  active  (allowable  limits  specification) 

requirements  application  identifiers  (ID5)  by  active 
allowable  limits  application  identifier  (ID20)  and  by 
OHMIS  service  area  (ID10) 

DL17:  List  of  allowable  limits  check  request  identifiers 
(ID22)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (ID10) 

0L22:  List  of  active  allowable  limits  application 

identifiers  (ID20)  by  form  specification  identifier 
(ID16)  and  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 


Identify  the  forms  specification  identifier  (ID16)  on  the 
DS18  data  from  Rl,  i.e.,  the  ID16  for  the  form  being 
entered  in  this  execution  of  Function  F3B.  Identify  the 
completed  form  identifier  (ID18)  and  the  OHMIS  service 
area  identifier  (ID10)  on  this  set  of  DS18  data. 


! 

* 
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PI: 
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P2:  Using  DL22,  identify  each  of  the  allowable  limits 

application  identifiers  (ID20)  for  the  ID16  and  for  the 
1010  from  Pi.  Put  on  a  list  called  the  P2  list. 

FNl:  FOR  each  of  the  1020s  on  the  P2  list: 

P3:  Locate  the  DS16  data  corresponding  to  the  1020. 

P4:  Compare  the  allowable  limits  applicability  values 

specified  in  the  DS16  data  from  P3  with  the  values  for  the 
corresponding  data  element  types  on  the  0S18  data  from  Rl. 
Do  they  match  (i.e.,  are  the  values  in  the  DS16  data 
either  blank  (no  specification  for  the  data  element  type) 
or  equal  to  (or  have  a  range  of  values  that  contains  a 
value  that  is  equal  to)  the  value  for  the  corresponding 
data  element  type  in  the  DS18  data)?  Yes  (i.e.,  the 
allowable  limits  specification  data  (DS17)  or  series  of 
DS17  data  with  the  1020  for  this  iteration  of  FNl  is  the 
applicable  allowable  limits  specification  data  for  the 
form  being  entered  in  this  execution  of  Function  F3B)  = 

P5;  No  =  P7 

P5:  Enter  the  ID20  for  this  iteration  of  FNl  onto  the  DS18 

data  from  Rl. 

P6:  GO  TO  P9. 

P7 :  NEXT  FNl;  end  of  FNl,  GO  TO  P8. 

P8:  Erase  the  set  of  D518  data  from  Rl;  erase  the  allowable 

limits  check  request  identifier  (ID22)  for  this  set  of 
DS18  data  from  the  DL17  list.  GO  TO  PI  of  Step  F3B-11. 

P9:  Using  the  DL16  list,  make  a  temporary  list  called  the  P9 

list  of  all  of  the  (allowable  limits  specification) 
requirement  application  identifiers  (105)  that  match  the 
1020  on  the  DS18  data  from  Rl  (i.e.,  the  ID20  entered  on 
the  DS18  data  in  P5). 

FN2:  FOR  each  105  on  the  P9  list: 


P10:  Is  this  the  first  ID5  on  the  P9  list?  Yes  =  P13;  No  =  Pll 

Pll:  Begin  generating  a  new  set  of  DS18  data  in  the  same  way  as 

described  in  P4  through  P6  of  Step  F3B-8.  Referred  to  as 
the  Pll  DS18  data. 

P12:  Add  the  ID22  for  the  new  DS18  data  generated  in  Pll  to  the 

0L17  list  for  the  1018  and  1010  identified  in  PI. 


1 
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P13:  Enter  the  105  for  this  iteration  of  FN2  on  the  DS18  data 

from  either  or  one  (if  the  answer  to  P10  was  'Yes')  or  Pll 
(if  the  answer  to  P1Q  was  'No'). 

P14:  Locate  the  DS17  data  for  the  ID5  for  this  iteration  of 

FN2. 

P15:  Using  the  0S17  data  from  P14,  identify  which  of  the  up  to 

nine  forms  units  for  the  form  in  this  execution  of 
Function  F3B  (i.e.,  the  forms  units  identified  in  P6  of 
Step  F3B-8  and  entered  onto  the  DS18  data  from  R1  or  the 
DS18  data  from  Pll)  are  to  be  used  to  evaluate  allowable 
limits.  Enter  this  information  on  the  DS18  data  from 
either  R1  (if  the  answer  to  P10  was  'Yes')  or  Pll  (if  the 
answer  to  P10  was  'No'). 

P16:  Using  the  DS17  data  from  P14,  identify  which  of  the  up  to 

nine  forms  units  for  the  form  in  this  execution  of 
Function  F3B  are  to  be  used  as  requirement  implementation 
units  should  a  match  be  found  with  the  allowable  limits 
specifications  specified  in  this  DS17  data.  Enter  this 
information  on  the  0S1 8  data  from  either  R1  (if  the  answer 
to  P10  was  'Yes')  or  Pll  (if  the  answer  to  Pll)  was  'No'). 

?17 :  NEXT  FN2;  end  of  FN2,  GO  TO  P18. 

P18:  GO  TO  PI  of  Step  F3B-11. 

P19:  (Follows  P10  out  of  Step  F3B-9.)  Identify  the  forms 

specification  identifier  (ID16)  on  the  DS18  data  from  Rl, 
i.e.,  the  1016  for  the  form  being  entered  in  this 
execution  of  Function  F3B.  Identify  the  OHMIS  service 
area  identifier  (ID10)  on  this  set  of  DS18  data. 

P20:  Using  the  DL22  list,  identify  each  of  the  allowable  limits 

application  identifiers  (ID20)  for  the  ID16  and  I DIO  from 
P19.  Put  on  a  temporary  list  called  the  P20  list. 

FN3:  FOR  each  of  the  ID20s  on  the  P20  list: 

P21:  Locate  the  0S16  data  corresponding  to  the  ID20. 

FN3.1:  FOR  each  of  the  data  element  type  codes  (CT4)  from  R2 

(i.e.,  the  allowable  limits  applicability  factors  for  the 
form  being  entered  in  this  execution  of  Function  F3B): 

P22:  Does  the  0S16  data  for  P21  contain  allowable  limits 

applicability  criteria  (i.e.,  a  specified  value)  for  the 
data  element  type  in  this  iteration  of  FN3.I?  Yes  (i.e., 
this  data  element  type  is  one  of  the  factors  that 
determines  the  applicability  of  the  allowable  limits  on 
this  set  of  DS16  data;  can  be  blank  because  not  all  sets 
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of  applicability  values  (DS16)  have  to  use  all  of  the 
applicability  factors  ( DS15 ) )  =  P23;  No  =  P27 

P23:  Does  the  DS18  data  from  R1  contain  a  value  for  the  data 

element  type  in  this  iteration  of  FN3.1?  Yes  (i.e.,  the 
current  OHMIS  data  base  did  contain  this  value  and  the 
program  was  able  to  abstract  it  in  P5  of  Step  F3B-9)  = 

P26;  No  =  P24 

P24:  Generate  a  flag,  called  the  P24  flag.  Store  a  code  (e.g., 

'A')  in  the  P24  flag.  The  code  'A'  indicates  that  at  this 
point  in  the  FN3  loop  (i.e.,  for  this  iteration  of  FN3.1) 
it  is  not  possible  to  rule  out  the  DS18  data  from  R1 
(i.e.,  the  form  being  entered  in  this  execution  of 
Function  F3B)  as  definitely  not  matching  the  specified 
allowable  limits  applicability  values  given  in  the  DS16 
data  corresponding  to  the  ID20  for  this  iteration  of  FN3 
(i.e.,  the  DS16  data  identified  in  P21).  That  is,  unless 
there  is  a  set  of  DS16  data  (i.e.,  an  ID20)  that  is  found 
to  definitely  match  at  some  later  point  in  this  FN3  loop, 
it  will  be  necessary  to  obtain  the  DS18  data  from  R1  and 
have  the  user  manually  check  for  allowable  limits  (i.e., 
conduct  an  allowable  limits  check  (Function  F3C ) )  to 
determine  if  there  are  any  applicable  allowable  limits 
specifications. 

P25 :  GO  TO  P27. 

P26:  Does  the  value  for  the  data  element  type  in  this  iteration 

of  FN3.1  in  the  DS16  data  from  P21  match  the  value  for  the 
same  data  element  type  in  the  DS18  data  from  Rl?  Yes  = 
P27;  No  (i.e.,  the  allowable  limits  applicability  values 
in  the  set  of  DS16  data  in  this  iteration  of  FN3  can  be 
definitely  determined  not  to  match  the  values  in  the  DS18 
data  from  Rl  and  therefore  the  allowable  limits 
specifications  (DS17)  that  correspond  to  the  1020  and  this 
iteration  of  FN3  are  known  not  to  be  applicable  to  the 
form  beinq  entered  in  this  execution  of  Function  F3B)  = 

P33 

P27:  NEXT,  FN3.1;  end  of  FN3.1,  GO  TO  P28. 

P28:  Is  there  a  code  'A'  in  the  P24  flag?  Yes  =  P31;  No  (i.e., 

the  allowable  limits  specification  data  (DS17)  or  series 
of  DS17  data  with  the  ID20  for  this  iteration  of  FN3  is 
the  applicable  allowable  limits  specification  data  for  the 
form  being  entered  in  this  execution  of  Function  F3B)  = 

P29 

P29:  Enter  the  ID20  for  this  iteration  of  FN3  onto  the  DS18 

data  from  Rl. 
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P30:  GO  TO  P9. 

P31:  Erase  the  flag  in  P24. 

P32:  Generate  a  flag  called  the  P32  flag.  Fill  this  flag  with 

the  code  1 B‘  indicating  that  there  is  at  least  one  set  of 
DS16  data  for  which  it  was  not  possible  to  determine 
whether  this  DS16  data  identifies  the  applicable  allowable 
limits  for  the  form  being  entered  in  this  execution  of 
Function  F3B.  That  is,  unless  a  match  to  the  allowable 
limits  applicability  values  given  in  other  sets  of  DS16 
data  is  found  (i.e.,  in  other  iterations  of  FN3),  it  will 
not  be  possible  to  identify  which  set  of  allowable  limits 
specifications  are  applicable  and  an  allowable  limits 
check  (Function  F3C)  will  need  to  be  conducted. 

P33:  NEXT  FN3;  end  of  FN3,  GO  TO  P34. 

P34:  Is  there  a  code  *  B*  in  the  P32  flag?  Yes  (i.e.,  it  is  not 

possible  to  determine  which  are  the  applicable  allowable 
limits  for  the  form  being  entered)  =  P18;  No  (i.e.,  it  was 
possible  to  determine  that  none  of  the  allowable  limits 
specifications  are  applicable  to  the  form  being  entered  in 
this  execution  of  Function  F3B)  =  P8 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS18:  Allowable  limits  check  request  data  (for  a 
form-as-a-whole) 
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This  Step  begins  the  process  of  evaluating  allowable  limits  for  each 
of  the  data  elements  for  the  form  being  entered  in  this  execution  of 
Function  F3B.  In  this  Step,  the  program  determines  for  each  of  these 
data  element  types  whether  there  are  any  allowable  limits 
specifications  and,  if  so,  whether  there  are  default  allowable  limits 
specifications  for  the  data  element  type. 

Step  F3B-11  is  equivalent  to  Step  F3B-8  for  the  form-as-a-whole 
allowable  limits  evaluation. 

PREVIOUS  STEP:  Step  F38-11  follows  P3  of  Step  F3B-8;  or  of  Step 
F3B-9;  or,  P8  or  P18  of  Step  F3B-10. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 


Rl: 

Completed  form  identifier  (ID18)  retained  in  PI  of 
Step  F3B-1,  i.e.,  the  ID18  of  the  form  being  entered 
in  this  execution  of  Function  F3B 

R2: 

Next  available  allowable  limits  checks 
identifier  (ID22) 

request 

R3: 

Current  date 

DS10: 

Forms  description  data 

DS14: 

Completed  forms  data 

DS17 : 

Allowable  limits  specification  data 

DL15 : 

List  of  active  allowable  limits  application 
identifiers  (ID20)  by  forms  subpart  identifier  (ID17) 
and  by  OHMIS  service  area  (ID10) 

0L17: 

List  of  allowable  limits  check  request  identifiers 
(ID22)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (ID10) 

DL2Q: 

List  of  the  active  default  (allowable 
specification)  requirement  application 
(ID5)  by  the  forms  subpart  identifier 
the  OHMIS  service  area  (ID10) 

limits 
identifiers 
(1017)  and  by 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Locate  the  DS14  data  for  the  ID18  from  Rl.  Locate  the 

DS1U  data  corresponding  to  the  forms  specification 
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identifier  (1016)  for  this  DS14  data.  Also,  locate  the 
OHMIS  service  area  identifier  (1010)  and  previous  1018, 
if  any,  that  are  on  this  DS14  data. 

P2:  Using  the  DS10  data  identified  in  Pi,  form  a  temporary 

list  of  the  forms  subpart  identifiers  (1017)  contained  in 
the  form  being  entered  in  this  execution  of  Function  F38, 
i.e.,  the  contents  of  this  form.  This  is  called  the  P2 
list. 

FN1:  FOR  each  ID17  on  the  P2  list: 

P3:  Using  the  DL15  list,  determine  whether  there  are  any 

allowable  limits  specifications  data  (DS17)  for  the  I Dl 7 
for  this  iteration  of  FNl  and  the  1010  identified  in  Pi, 
i.e.,  whether  there  are  any  allowable  limits  specified  for 
entering  any  of  the  data  elements  in  the  forms  subpart  in 
this  iteration  of  FNl.  Yes  =  P 4 ;  No  =  P24 

P4:  Add  the  1017  for  this  iteration  of  FNl  to  a  list  of  I D 1 7 s 

called  tne  P 4  list.  Retain  this  list  throughout  Function 
F3B. 

P5:  Begin  generating  a  set  of  DS18  data  for  the  forms  subpart 

in  this  iteration  of  FNl.  Assign  the  ID22  from  R2;  the 
ID10  from  PI;  the  date  from  R3;  the  ID18  from  R1  as  the 
first  ID18,  i.e.,  the  ID18  identifying  the  DS’.A  data  from 
PI  for  the  form  being  entered  in  this  execution  of 
Function  F36;  and,  the  ID18  from  the  previous  set  of 
DS14  data,  if  any,  from  PI.  Identify  this  set  of  DS18 
data  as  for  a  forms  subpart  (i.e.,  assign  the  answer  '1'). 
Assign  the  forms  specification  identifier  (1016)  from  PI. 
Assign  the  1017  from  this  iteration  of  FNl. 

P6:  Using  the  DS10  data  from  PI,  identify  the  up  to  6  types  of 

forms  units  that  apply  to  the  forms  subpart  (ID17)  in  this 
iteration  of  FNl. 

P7:  Obtain  the  values  (identifiers)  for  the  types  of  forms 

unit(s)  identified  in  P6  for  the  DS14  data  from  PI  and 
enter  these  values  onto  the  DS18  data  generated  in  P5. 

P8:  Locate  the  0511  data  corresponding  to  the  I Dl 7  in  this 

iteration  of  FNl. 

P9:  Identify  each  of  the  up  to  6  data  element  types  that  make 

up  the  forms  subpart  (ID17)  for  this  iteration  of  FNl. 

Put  on  a  temporary  list  called  the  P9  list. 

P10:  Using  the  DSld  data  from  PI  and  the  DS11  data  from  P8, 

locate  the  value  for  each  of  the  6  data  element  types 
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identified  on  the  P9  list  on  the  DS14  data  from  PI.  Enter 
these  values  on  the  DS18  data  generated  in  P5. 

Pll:  Add  the  1022  assigned  to  the  0S18  data  generated  in  P5  to 

the  DL17  list  for  the  ID18  and  the  ID10  identified  in  PI. 

P12:  Using  the  DL20  list,  determine  whether  there  is  only  a 

default  set  (or  a  default  series  of  sets)  of  allowable 
limits  specifications  data  (DS17)  for  the  ID17  in  this 
iteration  of  FNl  and  the  ID10  from  PI.  Yes  (i.e.,  there 
is  only  one  set  or  one  series  of  sets  of  allowable  limits 
for  this  1017  and  it  applies  in  all  cases)  =  P15;  No 
(i.e.,  there  are  one  or  more  sets  of  allowable  limits  for 
this  1017  and  each  is  to  be  used  (is  applicable)  in  only 
limited  cases;  therefore,  it  is  necessary  to  determine 
which  set  or  series  of  sets  of  allowable  limits  data 
applies  to  the  1017  in  this  iteration  of  FNl)  =  P13 

P13:  Put  the  ID17  for  this  iteration  of  FNl  on  a  list,  called 

the  P 13  list.  This  is  the  list  of  forms  subparts  for 
which  it  will  be  necessary  to  determine  if  there  are 
applicable  allowable  limits. 

P14:  GO  TO  P24 . 

P15:  Using  the  DL20  list,  identify  the  requirement  application 

identifier  (105)  or  series  of  ID5s  that  are  default  DS17 
sets  for  the  1017  in  this  iteration  of  FNl.  Put  the  ID5s 
on  a  list  called  the  P15  list.  Retain  this  list 
throughout  Function  F38. 

FNl . 1 :  FOR  each  105  on  the  P15  list: 

P16:  Is  this  the  first  105  on  the  P15  list?  Yes  =  P19;  No  = 

P17 

P17:  Begin  generating  a  new  set  of  0518  data  as  described  in  P5 

through  P10.  Refer  to  this  as  the  P17  DS18  data. 

P18:  Add  the  ID22  for  the  new  DS18  data  generated  in  P17  to  the 

DL17  list  for  the  1018  and  JD10  identified  in  PI. 

P19:  Enter  the  105  for  this  iteration  of  FN1.1  on  the  DS18  data 

from  either  P5  (if  the  answer  to  P16  was  ’Yes')  or  P17  (if 
the  answer  to  P 16  was  'No'). 

P20:  Locate  the  0S17  data  for  the  105  from  this  iteration  of 

FNl .  1 . 

P21 :  Using  the  DS17  data  from  P20,  identify  which  of  the  up  to 

6  forms  units  for  the  ID17  in  tnis  iteration  of  FNl  (that 
were  entered  on  the  DS18  data  from  P5  or  P17)  are  to  be 
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used  to  evaluate  allowable  limits.  Enter  this  information 
on  the  DS18  data  generated  in  either  P5  (if  the  answer  to 
P16  was  'Yes')  or  P17  (if  the  answer  to  P16  was  'No'). 

P22:  Using  the  DS17  data  from  P20,  identify  which  of  the  up  to 

6  forms  units  for  the  ID17  in  this  iteration  of  FN1  are  to 
be  used  as  requirement  implementation  units  should  a 
match  be  found  to  the  allowable  limits  specified  in  this 
DS17  data.  Enter  this  information  on  the  DS18  data  from 
either  P5  (if  the  answer  to  P16  was  ’Yes')  or  P17  (if  the 
answer  to  P16  was  'No'). 

P23:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P24. 

P24:  NEXT  FNl ;  end  of  FNl ,  GO  TO  P25. 

P25 :  GO  TO  Pi  of  Step  F3B-12. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS18:  Allowable  limits  check  request  data  (for  a  forms  subpart) 


STEP  F3B-12 


For  each  of  the  sets  of  data  element  types  (contained  in  forms 
subparts)  on  the  form  being  entered  in  this  execution  of  Function  F3B 
for  which  there  are  potentially  applicable  allowable  limits 
specifications  and  these  were  not  determined  in  Step  F3B-11  to  be  the 
default  allowable  limits  specifications  (i.e.,  for  which  it  is 
necessary  to  determine  which  allowable  limits  specifications  are 
applicable)  identify  the  factors  that  determine  which  allowable  limits 
specifications  are  applicable.  Obtain  the  values  for  these  factors 
from  the  current  OHMIS  data  base,  if  available,  and  store  them. 
Identify  those  data  element  types  fo*-  which  it  was  not  possible  to 
obtain  some  or  all  of  these  values. 

Step  F3B-12  is  equivalent  to  Step  F3B-9  for  the  form-as-a-whole 
allowable  limits  evaluation. 

PREVIOUS  STEP:  Step  F3B-12  follows  P25  of  Step  F3B-11. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  The  list  of  forms  subpart  identifiers  (ID17)  retained 

in  P13  of  Step  F3B-11,  i.e.,  the  list  of  IDI7s  for 
which  there  are  potential ly  applicable  allowable 
limits  specifications,  but  for  which  it  has  not  yet 
been  determined  whether  the  allowable  limits 
specifications  are  in  fact  applicable 

R2:  The  completed  form  identifier  (1D18)  retained  in  PI 

of  Step  F3B-1,  i.e.,  the  ID18  for  the  form  being 
entered  in  this  execution  of  Function  F3B 

0S7:  Data  element  type  information 

DS14:  Completed  forms  data 

DS15:  Allowable  limits  applicability  factors  data 

DS18:  Allowable  limits  check  request  data 

DL17:  List  of  allowable  limits  check  request  identifiers 
(1022)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  ( I DIO ) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 


PI: 


Does  the  list  from  Rl  (i.e.,  the  list  of  ID17s  for  which 
it  is  necessary  to  determine  if  there  are  applicable 
allowable  limits  specif ications)  contain  any  value? 
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Yes  =  P 3 ;  No  (i.e.,  there  are  no  ID17s  for  which  the 
applicable  allowable  limits  specifications  have  not  been 
identified)  =  P2 

P2:  GO  TO  PI  of  Step  F3B-16. 

P3:  Locate  the  DS14  data  corresponding  to  the  ID18  from  R2 

(i.e.,  the  data  for  the  form  being  entered  in  this 
execution  of  Function  F3B).  Locate  the  OHMIS  service 
identifier  (1010)  on  this  DS10  data. 

P4:  Using  the  DL17  list,  locate  all  allowable  limits  check 

request  identifiers  (ID 22)  for  the  ID1 8  from  R2  and  the 
ID10  from  P3.  Put  on  a  temporary  list  called  the  P4  list. 

FNl:  FOR  each  1022  on  the  P4  list: 

P5:  Locate  the  DS18  data  corresponding  to  this  1022. 

P6:  Locate  the  forms  subpart  identifier  (ID17)  on  the  DS18 

data  from  P5,  i.e.,  the  ID17  for  which  applicable 
allowable  limits  are  being  identified  in  this  iteration  of 
FNl. 

P7:  Is  the  ID17  from  P6  on  the  R1  list?  Yes  (i.e.,  this  is 

DS18  data  for  which  applicable  allowable  limits 
specifications  need  to  be  identified)  *  P8;  No  =  P 18 

P8:  Locate  the  DS15  data  for  the  ID17  from  P6  and  the  ID10 

from  P3. 

P9:  Abstract  from  the  DS15  data  located  in  P8  the  up  to  5  data 

element  type  codes  (CT4)  for  the  allowable  limits 
applicability  factors  for  each  of  the  up  to  6  forms 
units  for  the  forms  subpart  identified  in  P6.  Enter  these 
CT4s  onto  the  DS18  data  from  P5. 

FNl.l:  FOR  each  of  the  CT4s  identified  in  P9,  i.e.,  each  of  the 
factors  that  determine  allowable  limits  specifications  are 
applicable  to  the  forms  subpart  identified  in  P6: 

P10:  Use  the  DS7  data  to  determine  where/how  to  locate  the 

value  for  the  data  element  type  in  this  iteration  of 
FNl.l.  Determine  whether  the  current  OHMIS  data  base 
contains  a  value  for  this  data  element  type  (this 
allowable  limits  applicability  factor)  for  the  forms 
unit(s)  shown  on  the  form  being  entered  in  this  execution 
of  Function  F3B  that  correspond  to  the  forms  subpart 
(ID17)  (  as  identified  on  the  DS18  data  from  P5).  Yes 
(i.e.,  the  current  OHMIS  data  base  does  contain  the  value 
for  one  of  the  data  element  types  that  will  determine 
which  allowable  limits  specifications  are  applicable)  = 
Pli;  No  =  P 12 
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Pll:  Enter  the  value  for  the  allowable  limits  applicability 

factor  (i.e.,  the  value  for  the  CT4  for  this  iteration  of 
FNl.l)  on  the  DS18  data  from  P5. 

P12:  NEXT  FNl.l;  end  of  FNl.l,  60  TO  P13. 

P13:  Review  the  0S18  data  from  P5.  Do  al 1  of  the  allowable 

limits  applicability  factors  (i.e.,  the  CT4s  identified  in 
P9)  have  values  entered  on  the  DS18  data  from  P5?  Yes 
(i.e.,  there  is  information  on  the  DS18  data  from  P5  to 
determine  which  allowable  limits  specifications  are 
applicable  to  the  forms  subpart  data  (ID17)  from  P6,  i.e., 
the  forms  subpart  for  this  iteration  of  FNl)  =  P15;  No  = 
P14 

P14:  Do  some  of  the  allowable  limits  applicability  factors 

have  values  entered  on  the  DS18  data  from  P5?  Yes  =  P17; 
No  (i.e.,  it  is  not  possible  to  determine  which  allowable 
limits  are  applicable  and  therefore  an  allowable  limits 
check  (Function  F3C)  will  need  to  be  conducted)  =  P18 

P15:  Place  the  ID22  from  this  iteration  of  FNl  on  a  temporary 

list  called  the  P15  list.  Retain  throughout  Function  F3B. 

P16:  GO  TO  P18. 

P17:  Place  the  1022  for  this  iteration  of  FNl  on  a  temporary 

list,  called  the  P17  list.  Retain  throughout  Function 
F3B. 

P18:  NEXT  FNl;  end  of  FNl,  GO  TO  P19. 

P19:  GO  TO  PI  of  Step  F3B-13. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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Determine  whether  there  are  any  allowable  limits  specifications 
applicable  to  the  forms  subparts  that  make  up  the  form  that  is  being 
entered  in  this  execution  of  Function  F3B,  i.e.,  whether  these 
specified  values  for  the  allowable  limits  applicability  factors  for 
each  type  of  forms  subpart  match  the  values  for  the  particular  forms 
subpart  entered  on  this  form  or  the  values  for  the  characteristics  of 
the  forms  units  corresponding  to  each  forms  subpart.  If  there  are 
applicable  allowable  limits  specifications,  store  the  information  on 
the  identification  of  these  specifications  on  an  allowable  limits 
check  request  data  set  (DS18). 

Step  F3B-13  is  equivalent  to  Step  F3B-10  for  the  form-as-a-whole 
allowable  limits  evaluation. 

PREVIOUS  STEP:  Step  F3B-13  follows  P19  of  Step  F3B-12  or  follows 
P20  of  F3B-15,  if  this  execution  of  Function  F3B  is  for  a  Missing  Data 
Element  Type  Form. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  The  list  of  allowable  limits  check  request 

identifiers  (ID22)  that  contain  all  of  the 
information  needed  to  determine  whether  there  are  any 
applicable  allowable  limits.  Retained  in  P15  of  Step 
F3B-12  or  from  P16  of  Step  F3B-15  if  this  execution 
of  Function  F3B  is  for  a  Missing  Data  Element  Type 
Form 

R2:  The  list  of  allowable  limits  check  request 

identifiers  (ID22)  that  contain  some  of  the 
information  needed  to  determine  whether  there  are  any 
applicable  allowable  limits.  Retained  in  P17  of  Step 
F3B-12  or  in  P18  of  Step  F3B-15  (for  Missing  Data 
Element  Type  Forms) 

DS17:  Allowable  limits  specification  data 

DS18:  Allowable  limits  check  request  data 

DL15:  List  of  active  allowable  limits  application 

identifiers  (1020)  by  forms  subpart  identifier  (IDI7) 
and  by  OHMIS  service  area  (1010) 

DL16:  List  of  active  (allowable  limits  specification) 

requirement  application  identifiers  (ID5)  by  active 
allowable  limits  application  identifier  (ID20)  and  by 
OHMIS  service  area  (ID10) 


J 
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DL17:  List  of  allowable  limits  check  request  identifiers 
(1022)  by  completed  form  identifier  (1018)  and  by 
OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

FN1:  FOR  each  allowable  limits  check  request  identifier  (ID 22) 

on  the  R1  list: 

PI:  Locate  the  DS18  data  corresponding  to  this  ID22. 

P2:  Identify  the  forms  subpart  identifier  (1017)  covered  on 

the  DS18  data  from  PI.  Also  identify  the  completed  form 
identifier  (1018)  and  the  OHMIS  service  area  identifier 
(1010)  on  the  DS18  data. 

P3:  Using  the  DL15  list,  identify  each  of  the  allowable  limits 

application  identifiers  (ID20)  for  the  ID17  and  ID10  from 
P2.  Put  on  a  list  called  the  P3  list. 

FN1.1:  FOR  each  of  the  ID20s  on  the  P3  list: 

P4:  Locate  the  0S16  data  corresponding  to  the  ID20. 

P5:  Compare  the  allowable  limits  applicability  values 

specified  in  the  0S16  data  from  P4  with  the  values  for  the 
corresponding  data  element  types  on  the  DS18  data  from  Pi. 
Oo  they  match?  That  is,  are  the  values  in  the  DS16  data 
either  blank  (no  specification  for  the  data  element  type) 
or  equal  to  (or  provide  a  range  that  contains  a  value 
equal  to)  the  value  for  the  corresponding  data  element 
type  in  the  DS18  data?  Yes  (i.e.,  the  allowable  limits 
specification  data  (DS17)  or  series  of  0S17  data  with  the 
1020  for  this  iteration  of  FNl.l  is  the  applicable 
allowable  limits  specification  data  for  the  forms  subpart 
in  this  iteration  of  FNl  (i.e.,  covered  by  the  DS18  data 
in  this  iteration  of  FNl))  =  P6;  No  =  P8 

P6:  Enter  the  1020  for  this  iteration  of  FNl.l  onto  the  DS18 

data  from  PI. 

P7:  GO  TO  Pll. 

P8:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P9. 

P9:  Erase  the  set  that  singular  of  DS18  data  from  PI;  erase 

the  1022  for  this  set  of  DS18  data  from  the  DL17  list. 


P10:  GO  TO  P21 . 
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Pll:  Using  the  0116  list,  make  a  temporary  list,  called  the  Pll 

list,  of  all  of  the  (allowable  limits  specifications) 
requirement  application  identifiers  (ID5)  that  match  the 
ID20  on  the  DS18  data  from  PI. 

FN1.2:  FOR  each  105  on  the  Pll  list: 

P12:  Is  this  the  first  105  on  the  Pll  list?  Yes  =  P15 ;  No  = 

P13 

P13:  Begin  generating  a  new  set  of  DS18  data  in  the  same  way  as 

described  in  P5  through  P10  of  Step  F3B-11  (or  P10  through 
P14  of  Step  F3B-15,  if  this  execution  of  Function  F3B  is 
for  a  Missing  Data  Element  Type  Form).  Refer  to  as  the 
P 13  OS  18  data. 

P14:  Add  the  ID22  for  the  new  DS18  data  generated  in  P13  to  the 

DL17  list  for  the  1018  and  1010  identified  in  P2. 

P15:  Enter  the  105  for  this  iteration  of  FN1.2  on  the  DS18  data 

from  either  PI  (if  the  answer  to  P12  was  'Yes')  or  P13  (if 
the  answer  to  P12  was  'No'). 

P16:  Locate  the  DS 17  data  for  the  ID5  from  this  iteration  of 

FNl.2. 

P17:  Using  the  DS17  data  from  P16,  identify  which  of  the  up  to 

six  forms  units  for  the  forms  subpart  (DS11;  ID17)  covered 
by  the  DS18  data  in  this  iteration  of  FNl  are  to  be  used 
to  evaluate  allowable  limits. 

P18:  Enter  the  information  obtained  in  P17  onto  the  DS18  data 

from  either  PI  (if  the  answer  to  P12  was  'Yes')  or  P 13  (if 
the  answer  to  P 12  was  'No'). 

P19 :  Using  the  DS17  data  from  P16,  identify  which  of  the  up  to 

six  forms  units  for  the  forms  subpart  covered  by  this 
iteration  of  FNl  are  to  be  used  as  requirement 
implementation  units  should  a  match  be  found  to  the 
allowable  limits  specified  in  this  DS17  data.  Enter  this 
information  onto  the  DS18  data  from  either  PI  (if  the 
answer  to  P 12  was  'Yes')  or  P13  (if  the  answer  to  P12  was 
'No'  ). 

P20:  NEXT  FNl. 2;  end  of  FNl. 2,  60  TO  P21 . 

P21:  NEXT  FNl;  end  of  FNl,  GO  TO  FN2  (P22). 

FN2:  FOR  each  of  the  allowable  limits  check  request 

identifiers  (1022)  on  the  R2  list: 


P22:  Locate  the  OS  Id  data  corresponding  to  this  ID22. 
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P23:  Identify  the  forms  subpart  identifier  (ID17)  on  the  DS18 

data  from  P22.  Also  identify  the  completed  form 
identifier  (1018)  and  the  OHMIS  service  area  identifier 
(1010)  on  the  DS18  data. 

P24:  Using  the  0L15  list,  identify  each  of  the  allowable  limits 

application  identifiers  (1020)  for  the  1017  and  ID10  from 
P23.  Put  on  a  temporary  list  called  the  P24  list. 

FN2.1:  FOR  each  of  the  1020s  on  the  P24  list: 

P25:  Locate  the  DS16  data  corresponding  to  the  ID20. 

P26:  Using  the  DS18  data  from  P22,  identify  each  of  the  data 

element  types  (CT4)  that  are  the  applicability  factors 
(i.e.,  the  factors  that  determine  which  allowable  limit  is 
applicable)  for  the  forms  subpart  (DS11;  ID17)  covered  by 
the  0S18  data  from  this  iteration  of  FN2.  Put  on  a  list 
called  the  P26  list. 

FN2.1.1:  FOR  each  of  the  CT4s  on  the  P26  list: 

P27:  Does  the  DS16  data  from  P25  contain  allowable  limits 

applicability  criteria  (i.e.,  a  specified  value)  for  this 
data  element  type?  Yes  (i.e.,  this  data  element  type  is 
one  of  the  factors  that  determines  the  applicability  of 
allowable  limits  on  this  set  of  DS16  data)  =  P28;  No  =  P31 

P28:  Does  the  DS18  from  P22  contain  a  value  for  the  data 

element  type  in  this  iteration  of  FN2.1.1?  Yes  (i.e.,  the 
current  OHMIS  data  base  did  contain  this  value  and  the 
program  was  able  to  abstract  it  in  P10  of  Step  F3B-12)  = 
P26;  No  =  P29 

P29:  Generate  a  flag,  called  the  P29  flag.  Store  a  code  (e.g., 

'A')  in  the  P29  flag.  The  crde  'A'  indicates  that  at  this 
point  in  the  FN2.1  loop  (i.e.,  for  this  iteration  of 
FN2.1.1)  it  is  not  possible  to  rule  out  the  DSI3  data  from 
P22  (i.e.,  the  forms  subpart  for  this  iteration  of  FN2)  as 
definitely  not  matching  the  specified  allowable  limits 
applicabil ity  values  given  in  the  DS16  data  corresponding 
to  the  1020  for  this  iteration  of  FN2.1  (i.e.,  the  0S16 
data  identified  in  P25).  That  is,  unless  there  is  a  set 
of  DS16  data  (1020)  that  is  found  to  definitely  match  at 
some  later  point  in  this  FN2.I,  it  will  be  necessary  to 
retain  the  DS18  data  from  P22  and  the  user  will  have  to 
conduct  an  allowable  limits  check  (i.e.,  Function  F3C)  to 
determine  if  there  are  any  applicable  allowable  limits 
specifications. 


P30 :  GO  TO  P32. 
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P31:  Does  the  value  for  the  data  element  type  in  this  iteration 

of  FN2.1.1  in  the  DS16  data  from  P25  match  the  value  for 
the  same  data  element  type  in  the  DS18  data  from  P22?  Yes 
=  P32;  No  ( i . e - ,  the  allowable  limits  applicability  values 
in  the  set  of  DS16  data  and  this  iteration  of  FN2.1  can  be 
definitely  determined  to  not  match  the  same  values  in  the 
DS18  data  from  P22  and  therefore  the  allowable  limits 
specifications  (DS17  data)  corresponding  to  the  DS16  data 
in  this  iteration  of  FN2.1  can  be  determined  to  definitely 
not  be  applicable)  =  P47 

P32:  NEXT  FN2.1.1;  end  of  FN2.1.1,  GO  TO  P33. 

P33:  Is  there  a  code  'A'  in  the  P29  flag?  Yes  =  P45;  No  (i.e., 

the  allowable  limits  specification  data  (DS17)  or  series 
of  DS17  data  with  the  ID20  for  this  iteration  of  FN2.1  is 
the  applicable  allowable  limits  specification  data  for  the 
forms  subpart  covered  in  this  iteration  of  FN2)  =  P34 

P34:  Enter  the  ID20  for  this  iteration  of  FN2.1  onto  the  DS18 

data  from  P22. 

P35:  Using  the  DL16  list,  make  a  temporary  list,  called  the  P35 

list,  of  all  of  the  (allowable  limits  specification) 
requirement  application  identifiers  (ID5)  that  match  the 
ID20  on  the  DS18  data  from  P22  (i.e.,  the  ID20  entered  on 
the  DS18  data  in  P34). 

FN2.1.2:  FOR  each  ID5  on  the  P35  list: 

P36:  Is  this  the  first  ID5  on  the  P35  list?  Yes  =  P39;  No  = 

P37 

P37:  Begin  generating  a  new  set  of  DSI8  data  in  the  same  way  as 

described  in  P5  through  P9  of  Step  F3B-11  (or  P10  through 
P14  of  Step  F3B-15  if  this  execution  of  Function  F3B  is 
for  a  Missing  Data  Element  Type  Form).  Refer  to  as  the 
P 37  DS18  data. 

P38:  Add  the  ID22  for  the  new  DS18  data  generated  in  P37  to  the 

DL17  list  for  the  ID18  and  I DIO  identified  in  P23. 

P39:  Enter  the  ID5  for  this  iteration  of  FN2.I.2  on  the  DS18 

data  from  either  P22  (if  the  answer  to  P 36  was  'Yes')  or 
P37  (if  the  answer  to  P36  was  'No'). 

P40:  Locate  the  DS 1 7  data  for  the  ID5  from  this  iteration  of 

FN2.1.2. 

P4I :  Using  the  DS17  data  for  P40  identify  which  of  the  up  to 

six  forms  units  for  the  forms  subpart  ( DS II;  ID17)  covered 
by  the  0S18  data  in  this  iteration  of  FN2  are  to  be  used 
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to  evaluate  allowable  limits.  Enter  this  information  on 
the  0S18  data  from  either  P22  (if  the  answer  to  P36  was 
'Yes')  or  P37  (if  the  answer  to  P36  was  'No'). 


P42 : 

Using  the  0S17  data  from  P40,  identify  which  of  the  up  to 
six  forms  units  for  the  forms  subpart  covered  by  this 
iteration  of  FN2  are  to  be  used  as  requirement 
implementation  units  should  a  match  be  found  to  the 
allowable  limits  specified  in  this  DS17  data.  Enter  this 
information  on  the  DS18  data  from  either  P22  (if  the 
answer  to  P36  was  ’Yes')  or  P37  (if  the  answer  to  P36  was 
'No' ). 

P43: 

NEXT  FN2.1.2;  end  of  FN2.1.2,  GO  TO  P44. 

P44: 

GO  TO  P50. 

P45 : 

Erase  the  flag  in  P29. 

P46 : 

Generate  a  flag  called  the  P46  flag.  Fill  this  flag  with 
a  code  (e.g.,  code  1 B*  )  indicating  that  there  is  at  least 
one  set  of  DS 16  data  for  which  it  was  not  possible  to 
determine  whether  this  DS16  data  identifies  the  applicable 
allowable  limits  for  the  forms  subpart  in  this  iteration 
of  FN2.  That  is,  unless  a  match  to  another  set  of  DS16 
data  is  found,  it  will  be  necessary  to  conduct  an 
allowable  limits  check  (Function  F3C)  to  determine  which 
allowable  limits  are  applicable. 

P47: 

NEXT  FN2.1;  end  of  FN2.1,  GO  TO  P48. 

P48: 

Is  there  a  code  ' B‘  in  the  P46  flag?  Yes  (i.e.,  it  is 
not  possible  to  determine  which  are  the  applicable 
allowable  limits  for  the  forms  subpart  (DS11;  ID17) 
covered  in  the  DS18  data  in  this  iteration  of  FN2)  =  P50; 
No  (i.e.,  it  was  possible  to  determine  that  none  of  the 
allowable  limits  specif ications  are  applicable  to  the 
forms  subpart  in  this  iteration  of  FN2)  =  P49 

P49: 

Erase  the  set  of  0S18  data  from  P22;  erase  the  allowable 
limits  check  request  identifier  (ID22)  for  this  set  of 

0S18  data  from  the  DL17  list. 

P50: 

NEXT  FN2;  end  of  FN2,  GO  TO  P5I . 

P51: 

GO  TO  PI  of  Step  F 38-16 . 

OUTPUTS  AND 

GENERATION  OF  DATA  SETS: 

OS lti :  Allowable  limits  check  request  data  (for  a  forms  subpart) 
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This  Step  begins  the  process  of  evaluating  allowable  limits  for  each 
of  the  missing  data  elements  for  the  Missing  Data  Element  Type  Form 
being  entered  in  this  execution  of  Function  F3B.  In  this  Step,  the 
program  determines  for  each  of  these  data  element  types  whether  there 
are  any  allowable  limits  specifications  and,  if  so,  whether  there  are 
default  allowable  limits  specifications  for  the  data  element  type. 

Step  F3B-14  is  equivalent  to  Step  F3B-11  for  the  allowable  limits 
evaluation  of  data  elements  on  a  regular  form  (i.e.,  not  a  Missing 
Data  Element  Type  Form). 

PREVIOUS  STEP:  Step  F3B-14  follows  P94  of  Step  F3B-7. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  retained  in  PI  of 

Step  F3B-1,  i.e.,  the  ID18  of  the  form  being  entered 
in  this  execution  of  Function  F3B 

R2:  Next  available  allowable  limits  checks  request 

identifier  (ID22) 

R3:  Current  date 

DS10:  Forms  description  data 

DS14:  Completed  forms  data 

DS17:  Allowable  limits  specification  data 

DS19:  Missing  data  element  information 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 

DL15:  List  of  active  allowable  limits  application 

identifiers  (ID20)  by  forms  subpart  identifier  (ID17) 
and  by  OHMIS  service  area  (ID10) 

DLI7:  List  of  allowable  limits  check  request  identifiers 
(1022)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (ID10) 

DL20:  List  of  the  active  default  (allowable  limits 

specification)  requirement  application  identifiers 
(ID5)  by  the  forms  subpart  identifier  (ID17)  and  by 
the  OHMIS  service  area  ( I DIO ) 
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PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Locate  the  DS22  data  corresponding  to  the  1018  from  Rl. 

FN1:  FOR  each  of  the  missing  data  element  type  information 

identifiers  (1021)  on  the  DS22  data  from  Pi: 

P2:  Locate  the  DS19  data  corresponding  to  the  ID21.  Use  this 

data  to  identify  the  data  element  type  that  was  missing 
and  was  entered  onto  the  OHMIS  data  base  using  the  Missing 
Data  Element  Type  Form  in  this  execution  of  Function  F3B. 

P3:  Using  the  DS19  data  from  P2,  determine  if  the  missing  data 

element  type  for  this  iteration  of  FN1  is  stored  on  an 
OHMIS  form.  Yes  =  P5;  No  =  P4 

M:  GO  TO  P28. 

P5:  Use  the  DS19  data  to  identify  the  completed  form 

identifier  (ID18)  for  the  completed  forms  data  (DS14)  from 
which  the  missing  data  element  type  in  this  iteration  of 
FNl  was  missing. 

P6:  Locate  the  DS14  data  corresponding  to  the  ID18  from  P5. 

Also,  identify  the  DS10  data  corresponding  to  the  forms 
specification  identifier  (ID16)  on  this  DS14  data.  Also, 
identify  the  OHMIS  service  area  identifier  (ID10)  on  this 
DS 14  data  and  identify  the  previous  completed  form 
identifier  (1018),  if  any,  on  this  DS14  data. 

P7:  Using  the  DS19  data  from  P2,  identify  the  forms  subpart 

identifier  (ID17)  that  indicates  from  which  forms  subpart 
( DS 11)  on  the  form  the  missing  data  element  type  for  this 
iteration  of  FNl  was  missing. 

P8:  Using  the  DL 1 5  list,  determine  whether  there  are  any 

allowable  limits  specifications  data  (DS17)  for  the  ID17 
identified  in  P7  and  the  I DIO  identified  in  P6,  i.e., 
whether  there  are  any  allowable  limits  specified  for 
entering  any  of  the  data  elements  in  the  forms  subpart. 

Yes  =  P9;  No  =  P28 

P9:  Add  the  ID17  from  P7  to  a  list  of  I D1 7 s  called  the  P9 

list.  Retain  this  list  throughout  Function  F3B. 

P10:  Begin  generating  a  set  of  DS18  data  for  the  forms  subpart 

from  P7.  Assign  the  ID22  from  R2;  the  I  DIO  from  P6;  the 
date  from  R3;  the  I D18  from  P5  as  the  first  ID18,  i.e., 
the  ID18  identifying  the  DS14  data  from  P6  for  the  form 
onto  which  the  missing  data  element  being  entered  in  this 
iteration  of  FNl;  and,  the  ID18  from  the  previous  set  of 
DS14  data,  if  any,  from  P6.  Identify  this  set  of  DS18 


STEP  F3B-14 


data  as  for  a  forms  subpart  (i.e.,  assign  the  answer  '1'). 
Assign  the  forms  specification  identifier  (ID16)  from  P6. 
Assign  the  ID17  from  P7. 

P 1 1 :  Using  the  DS10  data  from  P6,  identify  the  up  to  6  types  of 
forms  units  that  apply  to  the  forms  subpart  (ID17)  from 
P7. 

P12:  Obtain  the  values  (identifiers)  for  the  types  of  forms 

unit(s)  identified  in  Pll  for  the  DS14  data  from  P6  and 
enter  these  values  onto  the  DS18  data  generated  in  P10. 

P13:  Locate  the  0S11  data  corresponding  to  the  ID17  from  P7. 

P 14 :  Using  the  DS10  data  from  P6  and  the  0S11  data  from  P13, 

locate  the  value  for  the  data  element  type  in  this 
iteration  of  FN 1  on  the  DS14  data  located  in  P6.  Enter 
this  value  on  the  DS18  data  generated  in  P10. 

P15:  Add  the  ID22  assigned  to  the  DS18  data  generated  in  P10  to 

the  DLl 7  list  for  the  1D18  identified  in  P5  and  the  I  DIO 
identified  in  P6. 

P16:  Using  the  0L20  list,  determine  whether  there  is  only  a 

default  set  (or  a  default  series  of  sets)  of  allowable 
limits  specifications  data  (DS17)  for  the  ID17  from  P7. 
and  the  ID10  from  P6.  Yes  (i.e.,  there  is  only  one  set  or 
one  series  of  sets  of  allowable  limits  for  this  ID17  and 
it  applies  in  all  cases)  =  P19;  No  (i.e.,  there  are  one  or 
more  sets  of  allowable  limits  for  this  ID17  and  each  is  to 
be  used  (is  applicable)  in  only  limited  cases;  therefore, 
it  is  necessary  to  determine  which  set  or  series  of  sets 
of  allowable  limits  data  applies  to  the  1017  from  P7)  = 

P17 

P17 :  Put  the  1021  for  this  iteration  of  FN 1  on  a  list  called 

the  P17  list.  This  is  the  list  of  missing  data  element 
types  for  which  it  will  be  necessary  to  determine  if  there 
are  applicable  allowable  limits. 

P18:  GO  TO  P28. 

P 19 :  Using  the  DL20  list,  identify  the  requirement  application 

identifier  (105)  or  series  of  1 05 s  that  are  default  DS17 
sets  for  the  1017  from  P7.  Put  the  105 s  on  a  list  called 
tne  P19  list.  Retain  this  list  throughout  Function  F3B. 

FNl.l:  FOR  each  105  on  the  P19  list: 

P 20:  Is  this  the  first  IDS  on  the  P19  list?  Yes  =  P23;  No  = 

P21 
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P21:  Begin  generating  a  new  set  of  0S18  data  as  described  in 

PIG  through  P14.  Refer  to  this  as  the  P21  DS18  data. 

P22:  Add  the  ID22  for  the  new  DS18  data  generated  in  P21  to  the 

DL17  list  for  the  1018  identified  in  P5  and  I  DIO 
identified  in  P6. 

P23:  Enter  the  ID5  for  this  iteration  of  FNl.l  on  the  DS18  data 

from  either  P10  (if  the  answer  to  P20  was  ’Yes')  or  P21 
(if  the  answer  to  P20  was  'No'). 

P24:  Locate  the  DS17  data  for  the  ID5  from  this  iteration  of 

FNl.l. 

P25 :  Using  the  DS17  data  from  P24,  identify  which  of  the  up  to 

6  forms  units  for  the  ID17  from  P7  (that  were  entered  on 
the  DS18  data  from  P10  or  P21)  are  to  be  used  to  evaluate 
allowable  limits.  Enter  this  information  on  the  DS18  data 
generated  in  either  P10  (if  the  answer  to  P20  was  ’Yes’) 
or  P21  (if  the  answer  to  P20  was  'No'). 

P26:  Using  the  DS17  data  from  P24,  identify  which  of  the  up  to 

six  forms  units  for  the  ID17  from  P7  are  to  be  used  as 
requirement  implementation  units  should  a  match  be  found 
to  the  allowable  limits  specified  in  this  DS17  data. 

Enter  this  information  on  the  DS18  data  from  either  P10 
(if  the  answer  to  P20  was  ’Yes')  or  P21  (if  the  answer  to 
P2U  was  '  No'  ) . 

P27 :  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P28. 

P28:  NEXT  FNl ;  end  of  FNl ,  GO  TO  P29. 

P29:  GO  TO  Pi  of  Step  F3B-15. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS18:  Allowable  limits  check  request  data  (for  a  forms  subpart) 
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For  each  of  the  data  element  types  on  the  Missing  Data  Element  Type 
Form  being  entered  in  this  execution  of  Function  F3B  for  which  there 
are  potentially  applicable  allowable  limits  specifications  and  these 
were  not  determined  in  Step  F3B-14  to  be  the  default  allowable  limits 
specifications  (i.e.,  for  which  it  is  necessary  to  determine  which 
allowable  limits  specifications  are  applicable)  identify  the  factors 
that  determine  which  allowable  limits  specifications  are  applicable. 
Obtain  the  values  for  these  factors  from  the  current  OHMIS  data  base, 
if  available,  and  store  them.  Identify  those  data  element  types  for 
which  it  was  not  possible  to  obtain  some  or  all  of  these  values. 

Step  F3B-15  is  equivalent  to  Step  F3B-12  for  the  allowable  limits 
evaluation  of  data  elements  on  a  regular  form  (i.e.,  not  a  Missing 
Data  Element  Type  Form). 

PREVIOUS  STEP:  Step  F3B-15  follows  P29  of  Step  F3B-14. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  The  list  of  missing  data  element  type  identifiers 

(ID21)  retained  in  P17  of  Step  F3B-14,  i.e.,  the  list 
of  ID21s  for  which  there  are  potentially  applicable 
allowable  limits  specifications,  but  for  which  it  has 
not  yet  been  determined  whether  the  allowable  limits 
specifications  are  in  fact  applicable 

R2:  The  completed  form  identifier  (ID18)  retained  in  PI 

of  Step  F3B-1,  i.e.,  the  ID18  for  the  Missing  Data 
Element  Type  Form  being  entered  in  this  execution  of 
Function  F3B 

DS7:  Data  element  type  information 

DS14:  Completed  forms  data 

DS15:  Allowable  limits  applicability  factors  data 

DS18:  Allowable  limits  check  request  data 

DS19:  Missing  data  element  information 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 

DL17:  List  of  allowable  limits  check  request  identifiers 
(ID22)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  ( 1  DIO ) 
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PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Does  the  list  from  R1  (i.e.,  the  list  of  missing  data 

element  types  (ID21s)  for  which  it  is  necessary  to 
determine  if  there  are  applicable  allowable  limits 
specifications)  contain  any  value? 

Yes  =  P3;  No  (i.e.,  there  are  no  ID21s  for  which  the 
applicable  allowable  limits  specifications  have  not  been 
identified)  =  P2 

P2:  GO  TO  PI  of  Step  F3B-16. 

FN 1 :  FOR  each  of  the  missing  data  element  type  information 

identifiers  (1021)  on  the  R1  list: 

P3:  Locate  the  0S19  data  corresponding  to  the  ID21. 

P4:  Use  the  DS19  data  from  P3  to  identify  the  completed  form 

identifier  (1018)  for  the  completed  forms  data  (DS14)  from 
which  the  missing  data  element  type  in  this  iteration  of 
FNl  was  missing. 

P5:  Locate  the  0S14  data  corresponding  to  the  ID18  from  P4. 

Identify  the  OHMIS  service  area  (1010)  on  this  DS14  data. 

P6:  Using  the  OLl 7  list,  locate  the  allowable  limits  check 

request  identifier  (1022)  for  the  ID18  and  the  1010  from 
P5.  Put  on  a  temporary  list  called  the  P6  list. 

P7:  Locate  the  0S18  data  corresponding  to  the  ID22  from  P6. 

P8:  Locate  the  forms  subpart  identifier  (ID17)  on  the  DS18 

data  from  P7,  i.e.,  the  ID17  for  which  applicable 
allowable  limits  are  being  identified  in  this  iteration  of 
FNl. 

P9:  Locate  the  DS15  data  for  the  ID17  from  P8  and  the  1010 

from  P5. 

P10:  Abstract  from  the  DS15  data  located  in  P9  the  up  to  5  data 

element  type  codes  (CT4)  for  the  allowable  limits 
applicability  factors  for  each  of  the  up  to  6  forms 
units  for  the  forms  subpart  identified  in  P6.  Enter  these 
CT4s  onto  the  DS18  data  from  P7. 

FN1.1:  FOR  each  of  the  CT4s  identified  in  P10,  i.e.,  each  of 

the  factors  that  determine  allowable  limits  specifications 
are  applicable  to  the  forms  subpart  identified  in  P8: 

Pll:  Use  the  DS 7  data  to  determine  where/how  to  locate  the 

value  for  the  data  element  type  in  this  iteration  of 
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FNl.l.  Determine  whether  the  current  OHMIS  data  base 
contains  a  value  for  this  data  element  type  (this 
allowable  limits  applicability  factor)  for  the  forms 
unit(s)  shown  on  the  form  onto  which  the  missing  data 
element  in  this  iteration  of  FNl  is  being  entered  that 
corresponds  to  the  forms  subpart  (ID17)  from  P8  (as 
identified  on  the  DS18  data  from  P7).  Yes  (i.e.,  the 
current  OHMIS  data  base  does  contain  the  value  for  one  of 
the  data  element  types  that  will  determine  which  allowable 
limits  specifications  are  applicable)  =  P12;  No  =  P13 

P12:  Enter  the  value  for  the  allowable  limits  applicability 

factor  (i.e.,  the  value  for  the  CT4  for  this  iteration  of 
FNl.l)  on  the  DS 18  data  from  P7. 

PI 3:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P14. 

P14:  Review  the  DS18  data  from  P7.  Do  al 1  of  the  allowable 

limits  applicability  factors  (i.e.,  the  CT4s  identified  in 
P10)  have  values  entered  on  the  DS18  data  from  P 7?  Yes 
(i.e.,  there  is  information  on  the  DS18  data  from  P5  to 
determine  which  allowable  limits  specifications  are 
applicable  to  the  forms  subpart  data  (ID17)  from  P8,  i.e., 
the  forms  subpart  for  this  iteration  of  FNl)  =  P16;  No  = 
P15 

P15:  Do  some  of  the  allowable  limits  applicability  factors 

have  values  entered  on  the  DS18  data  from  P7?  Yes  =  P18; 
No  (i.e.,  it  is  not  possible  to  determine  which  allowable 
limits  are  applicable  and  therefore  an  allowable  limits 
check  (Function  F3C)  will  need  to  be  conducted)  =  P19 

P16:  Place  the  ID22  from  P6  on  a  temporary  list  called  the  P16 

list.  Retain  throughout  Function  F3B. 

P17 :  GO  TO  P19. 

P 18 :  Place  the  ID22  from  P6  on  a  temporary  list,  called  the  P18 

list.  Retain  throughout  Function  F3B. 

PI 9:  NEXT  FNl;  end  of  FNl,  GO  TO  P20. 

P20:  GO  TO  PI  of  Step  F3B-13. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F3B-16 


Identify  the  complete  list  of  potential  allowable  limits 
specifications  that  need  to  be  evaluated;  there  can  be  none  or  one  or 
more  sets  of  allowable  limits  specifications  data  (DS17)  for  the 
form-as-a-whole  and  for  each  form  subpart  entered  as  a  part  of  the 
entry  of  the  form  for  this  execution  of  Function  F3B.  If  there  are  no 
such  allowable  limits  specifications,  end  Function  F3B.  For  each  such 
allowable  limits  specification,  determine  whether  the  allowable  limits 
evaluation  can  be  done  automatically,  i.e.,  in  Function  F3B,  or 
whether  the  user  must  conduct  a  manual  allowable  limits  check  in 
Function  F3C. 

PREVIOUS  STEP:  Step  F3B-16  follows  P2  of  Step  F3B-12;  P51  of  Step 
F3B-13;  or  P2  of  Step  F3B-15. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 
Data  Retrievals: 

Rl:  Completed  form  identifier  (IDI8)  for  the  form  being 

entered  in  this  execution  of  Function  F3B.  Retained 
in  PI  of  Step  F3B-1. 

R2:  OHM IS  user  type  (CT1).  From  P2  of  Step  F1A-2. 

DS17:  Allowable  limits  specification  data 

DS19:  Missing  data  element  information 

0S22:  Outstanding  (uncompleted)  forms  monitoring  data 

DL17:  List  of  allowable  limits  check  request  identifiers 
(ID22)  by  completed  form  identifier  (ID18)  and  by 
OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Locate  the  DS22  data  for  the  1018  from  Rl. 

P2:  Is  the  DS22  data  located  in  Pi  for  a  Missing  Data  Element 

Type  Form?  Yes  =  FNl  (P5);  No  =  P3 

P3:  Add  the  ID18  from  Rl  to  a  temporary  list  called  the  P3 

list.  Retain  this  list  throughout  Function  F3B. 

P4:  GO  TO  FN2  (Pll). 


FNl:  FOR  each  of  the  missing  data  element  type  information 

identifiers  (ID21)  on  the  DS22  data  from  Pi: 


STEP  F3B-16 


P5:  Locate  the  0S19  data  for  this  ID21. 

P6:  Using  the  DS19  data  from  P5,  determine  if  the  missing  data 

element  is  stored  on  an  OHMIS  form.  Yes  *  P8;  No  =  P7 

P7:  GO  TO  P10. 

P8:  Using  the  0S19  data  from  P5,  identify  the  completed  form 

identifier  (ID18)  for  the  completed  forms  data  (DS14)  from 
which  the  missing  data  element  type  in  this  iteration  of 
FN1  was  missing. 

P9:  Put  the  ID18  from  P8  onto  the  P3  list.  (Do  not  enter  this 

ID18  on  the  list  if  it  has  already  been  put  on  the  list.) 

P10:  NEXT  FNl;  end  of  FN1,  GO  TO  FN2  (Pll). 


FN2:  FOR  each  of  the  ID18s  on  the  P3  list: 


Pll:  Locate  the  DS14  data  corresponding  to  the  ID18  for  this 

iteration  of  FN2.  Identify  the  OHMIS  service  area 
identifier  (ID10)  on  this  DS14  data. 

P12:  Using  the  DL17  list,  identify  all  of  the  allowable  limits 

check  request  identifiers  (ID22)  for  the  1018  from  this 
iteration  of  FN2  and  the  1010  from  Pll.  Put  on  a 
temporary  list  called  the  P12  list  and  retain  throughout 
Function  F3B. 

P 1 3 :  NEXT  FN2 ;  end  of  FN2,  GO  TO  P14. 

P14:  Are  there  any  1022s  on  the  P12  list?  Yes  =  FN3  ( P 15 ) ;  No 

(i.e.,  there  are  no  allowable  limits  to  evaluate  for  this 
execution  of  Function  F3B)  =  P23 

FN3:  FOR  each  of  the  1022s  on  the  P12  list: 


P15:  Locate  the  DS18  data  for  the  1022. 

P16:  Determine  if  the  (allowable  limits  specification) 

requirement  application  identifier  (ID5)  field  on  the  DS18 
data  from  P15  is  filled,  i.e.,  whether  the  applicable 
allowable  limits  specifications  have  been  identified.  Yes 
=  PI 7 ;  No  (i.e.,  a  manual  allowable  limits  check  (Function 
F3C)  in  which  the  user  supplies  the  values  for  the 
applicability  factors  needed  to  determine  which  allowable 
limits  specifications  are  applicable  is  needed  for  the 
form-as-a-whole  or  for  the  forms  subpart  covered  in  this 
iteration  of  FN3,  i.e.,  the  automatic  allowable  limits 
evaluation  in  Function  F3B  is  ended)  =  P21. 


STEP  F3B-16 


P17:  Identify  the  105  on  the  DS18  data  from  P15. 

P18:  Locate  the  DS17  data  for  the  ID5  from  P17. 

P19:  Is  the  DS17  data  P17  for  an  allowable  limits  specification 

that  must  be  manual 1y  checked  (i.e.,  the  user  must 
evaluate  whether  the  allowable  limits  specifications  have 
been  met  because  the  type  of  allowable  limits 
specification  is  such  that  it  does  not  fit  the  format  for 
allowable  limits  specification  data  and,  therefore,  cannot 
be  evaluated  automatically)?  Yes  (i.e.,  it  is  not 
possible  to  automatically  evaluate  the  allowable  limits  in 
Function  F3B;  an  allowable  limits  check  (Function  F3C) 
must  be  conducted)  =  P21;  No  =  P20 

P20:  Add  the  1022  for  this  iteration  of  FN3  to  a  list,  called 

the  P20  list;  retain  throughout  Function  F3B. 

P21 :  NEXT  FN3;  end  of  FN3,  GO  TO  P22. 

P22 :  GO  TO  PI  of  Step  F38-17. 

P23:  Erase  the  DS22  data  with  the  1018  from  Rl. 

P24:  End  of  Function  F3B;  close  out  and  exit  to  the  appropriate 

Menu  'O'  (First  Level  Menu)  as  determined  by  the  CT1  from 
R2. 


OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


FUNCTION  3D 


Function  For  Cancelling  The  Monitoring  Of 
Outstanding  (Uncompleted)  OHMIS  Forms 

(Functional  Data  Flow) 


The  OHMIS  system  monitors  all  blank  forms  generated  (Function  F3A)  for 
the  purpose  of  data  entry  until  these  forms  are  completed  and  the  data 
is  entered.  Function  F3D  allows  the  user  to  indicate  that  an 
outstanding  (uncompleted)  form  is  not  going  to  be  submitted  .  This 
then  cancels  the  monitoring  of  the  unsubmitted  form. 

SUMMARY  OF  SUBFUNCTIONS: 

The  following  are  the  subfunctions  to  be  accomplished  under  this  OHMIS 
function: 

1.  Program  cancels  the  outstanding  (uncompleted)  forms 
monitoring  data  (DS22)  for  a  form  that  the  user  has 
indicated  is  not  going  to  be  submitted. 

2.  If  the  unsubmitted  form  is  a  Missing  Data  Element  Type 
Form,  the  program  changes  the  missing  data  element  type 
information  (DS19)  to  reflect  that  there  is  no  longer  an 
outstanding  data  request  (form)  for  the  missing  data 
element  types  that  were  on  the  Missing  Data  Element  Type 
Form,  i.e.,  these  data  element  types  are  now  eligible  for 
entry  on  a  new  Missing  Data  Element  Type  Form. 

TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


I 


STEP  F3D-1 


Identify  the  form  that  the  user  wishes  to  cancel.  Determine  if  this 
form  is  being  monitored. 

PREVIOUS  STEP:  None.  Step  F3D-1  occurs  when  the  user  decides  to 
cancel  an  outstanding  (uncompleted)  QHMIS  form  and  indicate  that  the 
form  is  not  going  to  be  submitted. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  3  (completed  forms  data  and  uncompleted  forms  data) 

S2:  6  (cancelling  an  outstanding  (uncompleted)  form, 

i.e.,  indicating  that  an  outstanding  form  is  not 
going  to  be  submitted) 

Ql:  Completed  form  identifier  (ID18)  for  the  form  that  is 

not  going  to  be  submitted.  This  identifier  is 
printed  on  the  form  (see  Output  012)  when  it  is 
generated.  Query  is  in  Pi. 


Data  Retrievals: 

Rl:  OHMIS  user  type  code  (CT1)  from  P2  of  Step  F1A-2 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 
PROCESSING  (P  =  Process  substep): 

PI:  Ask  user  for  Ql,  i.e.,  ID18.  Retain  this  ID18  throughout 

Function  F3D. 

P2:  Is  there  a  set  of  DS22  data  for  the  ID18  from  PI?  Yes  = 

P5;  No  =  P3 

P3:  Tell  user  that  this  form  was  not  being  monitored. 

P4:  End  of  Function  F3D.  Close  out  all  temporary  files  unless 

an  exit  to  the  appropriate  Menu  'O'  (First  Level  Menu)  as 
determined  by  the  CT1  from  Rl. 

P5:  GO  TO  PI  of  Step  F3D-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F3D-2 


Determine  if  the  form  that  the  user  wishes  to  cancel  is  a  Missing  Data 
Element  Type  Form.  If  not,  proceed  to  Step  F3D-3.  If  yes,  remove  the 
completed  form  identifier  (ID18)  from  each  set  of  missing  data  element 
information  (DS19)  for  the  missing  data  elements  covered  on  the  form. 
This  indicates  that  the  data  element  type  is  no  longer  being  requested 
on  a  Missing  Data  Element  Type  Form  and,  therefore,  is  eligible  to  be 
put  on  a  new  Missing  Data  Element  Type  Form  (see  Function  F3A). 

PREVIOUS  STEP:  Step  F3D-2  follows  P5  of  Step  F3D-1. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Comp  1 e ted  form  identifier  (ID18)  for  the  form  the 

user  wishes  to  cancel.  Retained  in  PI  of  Step  F3D-1. 

DS19:  Missing  data  element  information 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)): 

PI:  Locate  the  DS22  data  for  the  ID18  for  Rl. 

P2:  Is  the  DS22  data  from  P5  for  an  Missing  Data  Element  Type 

Form?  Yes  =  P 4 ;  No  =  P3 

P3:  GO  TO  PI  of  Step  F3D-3. 

P4:  Make  a  temporary  list  of  each  of  the  missing  data  element 

type  information  identifiers  (ID21)  on  the  DS22  data  from 
PI.  This  is  called  the  P4  list. 

FN 1 :  FOR  each  ID21  on  the  P4  list: 

P5:  Locate  the  DS19  data  for  the  ID21. 

P6:  Remove  the  ID18  from  Rl  from  the  DS19  data  located  in  P5, 

i.e.,  remove  the  identifier  indicating  that  this  missing 
data  element  is  currently  being  requested  on  a  Missing 
Data  Element  Type  Form. 

P7 :  NEXT  FN1 ;  end  of  FNi ,  GO  TO  P3. 


OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F3D-3 


Delete  the  outstanding  (uncompleted)  forms  monitoring  data  (DS22)  for 

the  form  that  the  user  wishes  to  cancel. 

PREVIOUS  STEP:  Step  F3D-3  follows  P3  of  Step  F3D-2. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  Completed  form  identifier  (ID18)  for  the  form  the 

user  wishes  to  cancel.  Retained  in  PI  of  Step  F3D-1. 

R2:  Current  date 

DS22:  Outstanding  (uncompleted)  forms  monitoring  data 

DL26:  List  of  new  outstanding  data  requests  (ID18)  (not 
overdue)  by  OHMIS  service  area  (ID10) 

DL27:  List  of  outstanding  data  requests  (ID18)  (no  due  date 
specified)  by  OHMIS  service  area  ( I  DIO ) 

DL28:  List  of  overdue  data  requests  (ID18)  by  OHMIS  service 
area  ( I  DIO ) 

PROCESSING  (P  =  Process  Substep): 

PI:  Locate  the  DS22  data  for  the  ID18  from  Rl.  Identify  the 

OHMIS  service  area  identifier  ( I  DIO )  on  this  DS22  data. 

P2:  Does  the  DS22  data  from  PI  specify  an  amount  of  time  from 

the  date  that  the  form  was  generated  before  the  form  is 
considered  to  be  overdue?  Yes  =  P5;  No  =  P3 

P3:  Locate  the  1018  from  Rl  and  the  I DIO  from  PI  on  the  DL27 

list.  Delete  the  ID18  and  I DIO  from  this  list. 

P 4:  GO  TO  P10. 

P5:  Calculate  the  past  due  date  for  the  form,  i.e.,  add  the 

amount  of  time  before  the  form  is  overdue  given  on  the 
DS22  data  from  PI  to  the  date  that  the  form  was  generated, 
also  given  on  the  DS22  data  from  PI, 

P6:  Is  the  past  due  date  from  P5  equal  to  or  later  than  the 

current  date  in  R2?  Yes  =  P 7 ;  No  =  P9 

P7:  Locate  the  1018  from  Rl  and  the  I DIO  from  Pi  on  the  DL28 

list  and  delete  the  1018  and  1010  from  the  list. 


STEP  F3D-3 


P8:  GO  TO  PIO. 

P9:  Locate  the  I D 18  from  R1  and  the  I  DIO  from  PI  on  the  DL26 

list  and  delete  the  1018  and  I  DIO  from  this  list. 

PIO:  Delete  the  DS22  data  from  PI. 

Pll :  GO  TO  P4  of  Step  F3D-1. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


FUNCTIONAL  DATA  FLOWS 


FOR  THE  F4  FUNCTIONS:  Scheduling  Functions 


These  Functional  Data  Flows  describe  the  processing  substeps  for 
scheduling  and  rescheduling  of  tasks  in  OHMIS.  All  types  of  tasks  are 
scheduled  using  the  same  program  logic.  Examples  of  tasks  that  might 
be  scheduled  include  the  conducting  of  medical  examinations, 
conducting  of  industrial  hygiene  surveys,  follow  up  on  hazards 
identified  or  corrective  actions  previously  found  to  be  needed,  etc. 

The  processing  steps  given  here  describe  the  automatic  scheduling  of 
OHMIS  tasks.  A  task  is  initiated  when  the  OHMIS  program  triggers  a 
requirement  (or  Reminder  Notice)  that  involves  the  performance  of  a 
"scheduleable"  action.  (An  "unschedu leable"  action  is  defined  in  the 
description  of  the  requirement  description  data  set  (DS1).)  That  is 
when  the  OHMIS  programs  (Functions  FIB,  F2A  or  F3B)  determine  that  a 
requirement  should  be  executed  (i.e.,  the  information,  date  or 
allowable  limit  previously  defined  as  necessitating  the  execution  of 
an  action  is  input  or  reached),  the  program  checks  the  requirement 
description  data  (DSD  to  determine  if  this  requirement  involves  the 
execution  of  a  scheduleable  task.  (In  the  case  of  a  Reminder  Notice 
(non-requirement  type  of  date  triggered  action,  the  suspense  data 
(DS4)  is  checked  to  determine  if  there  is  a  scheduleable  task 
involved.)  If  the  DS1  data  (or  DS4  data)  specifies  a  scheduleable 
task  (through  the  use  of  a  task  type  code  (CT8) ) ,  the  OHMIS  program, 
in  Function  FA,  automatically  (i.e.,  without  any  action  required  by 
the  user)  schedules  the  task. 

The  F 4  Functions,  therefore,  make  the  OHMIS  core  data  processing 
programs  an  independent  and  "self-sufficient11  hole.  The  entire 
process  of  executing  an  occupational  health  program — from  the  initial 
recognition  of  a  need  for  action  based  on  a  specified  requirement, 
thr  igh  the  identification  of  the  personnel  and  time  needed  to 
sci  :ule  the  task  involved  in  complying  with  the  requirement,  to  the 
monitoring  of  the  execution  of  these  tasks/requirements  —  is  containr 
in  the  OHMIS  core  data  processing  functions.  Moreover,  from  the 
standpoint  of  the  OHMIS  user  at  the  local  installation  level,  this 
entire  process  is  accomplished  without  the  need  for  any  intervention 
or  self-initiated  action  on  the  part  of  the  user,  other  than  the 
entering  of  the  OHMIS  data  (always  d^ne  in  a  standard  way)  that  will 
trigger  the  initiation  of  the  pro  ess  of  executing  an  occupational 
health  program. 

There  are  three  F4  Functions.  Function  P4A  (called  the  scheduling 
function)  schedules  tasks.  Function  F4B  (called  the  rescheduling 
function)  allows  the  user  to  input  data  affecting  the  scheduling  of 
tasks  (such  as  what  time  each  employee  who  will  be  performing  tasks 
has  available  for  scheduling)  and  identifies  those  tasks  that  need  to 
be  rescheduled,  because  of  the  changes  in  this  data.  Function  F4C 
(called  the  Function  for  Routine  Generation  of  Tentative  Monthly 


FUNCTIONAL  DATA  FLOWS 


Schedule  Availability  Data)  uses  the  standard  regular  weekly 
schedule  availability  information  about  the  availability  of  each 
employee  who  wi 1 1  perform  tasks  to  generate  a  tentative  "blank" 
monthly  schedule  of  time  available  for  scheduling  tasks. 


FUNCTION  F4A 


Scheduling  Function 
(Functional  Data  Flow) 


This  Functional  Data  Flow  describes  the  processing  necessary  to 
schedule  tasks  in  OHMIS.  The  task  scheduled  in  Function  F4A  are 
divided  into  two  groups:  ‘Employee  transport1  tasks  and  all  other 
tasks.  Employee  transport  tasks  are  distinguished  primarily  by  the 
fact  that  they  require  transporting  of  an  employee  away  from  his  work 
site  in  order  to  perform  the  task.  The  task  of  performing  a  medical 
examination  is  one  of  the  most  common  examples  of  an  employee 
transport  task.  In  this  case,  the  employee  who  is  participating  in 
the  task  (e.g.,  is  having  a  medical  examination)  as  distinguished  from 
the  employee  who  performs  the  task  (e.g.,  the  physician  conducting 
the  medical  examination)  must  be  transported  (or  at  least  removed 
from)  his/her  regular  work  site  to  participate  in  the  examination 
(task).  Employee  transport  tasks  are  scheduled  in  Steps  F4A-3  through 
F4A-5;  the  other  tasks  are  scheduled  in  Steps  F4A-6  and  F4A-7. 

Employee  transport  tasks  are  given  special  treatment  in  the  scheduling 
programs  for  two  reasons: 

The  program  attempts  to  reduce  the  number  of  times  that  an 
employee  must  be  transported  away  from  his  work  in  order 
to  participate  in  the  occupational  health  program.  This 
is  done  by  scheduling  employee  transport  tasks  for  the 
same  employee  at  approximately  the  same  time.  The 
reduction  in  the  number  of  times  that  the  employee  is 
contacted  by  OHMIS  to  a  degree  that  requires  participation 
in  the  occupational  health  program  away  from  his  regular 
work  site,  is  considered  to  be  critical.  This  is  because 
the  OHMIS  program  is  designed  to  allow  for  (but  not 
necessarily  prescribe)  more  frequent  interaction  between 
employees  and  the  Department  of  the  Army's  occupational 
health  program,  by  providing  a  means  to  trigger  and 
monitor  all  of  the  requirements  of  an  "ideal"  occupational 
health  program.  It  is  expected  that  if  such  an  "ideal" 
occupational  health  program  were  implemented  the  total 
number  of  contacts  with  employees  would  increase 
substantially  beyond  the  number  of  contacts  currently  made 
in  the  Department  of  the  Army's  occupational  health 
program.  To  allow  for  this  to  occur,  while  still 
minimizing  the  burden  on  the  work  force  of  participating 
in  such  a  program,  the  OHMIS  scheduling  program  has  many 
additional  features  that  allow  for  tasks  involving  the 
same  employee  to  be  scheduled  at  approximately  the  same 
time.  For  example,  the  criticality  of  this  scheduling 
selection  criteria  is  considered  so  important  that  the 
program  will  reschedule  already  scheduled  tasks  in  order 
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to  optimize  the  frequence  with  which  an  employee  must 
participate  in  employee  transport  tasks  as  a  part  of  the 
occupational  health  program. 

0  An  employee  transport  task,  by  definition,  necessarily 
involves  the  scheduling  of  two  persons,  i.e.,  both  the 
persons  performing  the  task  (e.g.,  the  pnysician 
conducting  the  medical  exam)  and  the  persons 
participating  in  the  task  (e.g.,  the  person  receiving  a 
medical  examination).  This  means  that  the  scheduling 
program  must  be  designed  so  that  multiple  tasks  are  not 
scheduled  to  overlap  with  other  tasks  that  are  either 
performed  by  the  same  person  or  tasks  in  which  the  same 
person  will  participate. 

These  two  stipulations  for  scheduling  selection  criteria  for  employee 
transport  tasks  add  greatly  to  the  complexity  (i.e.,  the  number  of 
processing  substeps)  of  the  scheduling  programs. 

The  OHMIS  scheduling  program  ’s  designed  to  schedule  tasks  based  on 
certain  scheduling  selection  criteria.  Thus,  the  program  does  not 
merely  look  for  an  "open"  time  slot  to  schedule  the  task,  but  also 
schedules  tasks  so  that: 

u  Tasks  are  performed  only  by  persons  designated  as  being 
qualified  to  perform  the  task 

The  tasks  are  not  interrupted  by  the  performance  of  any 
other  task 

0  The  tasks  are  not  scheduled  during  any  time  period  that  is 
restricted  for  the  task  or  for  the  requirement 
implementation  unit  (e.g.,  employee)  participating  in  the 
task.  For  example,  the  OHMIS  scheduling  program  assumes  a 
24-hour,  7-day  a  week  "working"  shift  and  identifies  those 
times  that  persons  are  not  available  to  perform  or 
participate  in  tasks  because  these  times  are  not  a  part  of 
their  regular  working  hours.  These  times  are  called 
"restricted"  times,  because  they  are  times  for  which  it  is 
not  acceptable  to  schedule  a  task.  These  restricted  times 
''c’  be  standard  restricted  times  (e.g.,  work  shift,  lunch 
„iaks,  etc.)  or  special  restricted  times  (e.g.,  leave 
times).  Similarly,  the  program  identifies  those  times 
that  facilities  (and  other  requirement  implementation 
units  that  are  the  unit  about  which  a  task  is  scheduled) 
are  not  available  for  scheduling  tasks.  For  example, 
there  may  be  times  when  a  facility  is  closed  down  and 
cannot  be  opened  to  conduct  an  industrial  hygiene  survey. 
These  times  would  be  considered  restricted  times  for 
conducting  tasks  involving  that  facility,  i.e.,  conducting 
tasks  in  which  that  facility  was  the  requirement 
implementation  unit. 
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In  addition  to  the  complexity  added  by  distinguishing  employee 
transport  tasks,  the  OHMIS  scheduling  program  is  made  more  powerful  by 
the  fact  that  it  attempts  to  not  merely  schedule  a  task,  but  to 
optimize  the  scheduling  of  the  task.  By  optimization  it  is  meant 
that  the  program  attempts  to  find  the  best  scheduling  option  available 
for  the  task.  The  optimization  process  is  based  on  several  scheduling 
selection  criteria,  including: 

0  Scheduling  tasks  "next  to'1  (i.e.,  at  approximately  the 
same  time)  other  similar  tasks.  This  includes  not  only 
optimizing  the  number  of  employee  transport  tasks  that  are 
scheduled  next  to  other  employee  transport  tasks  for  the 
same  employee  but  also  optimizing  the  frequency  with  which 
the  employees  performing  the  tasks  must  change  facilities 
to  perform  a  task.  The  OHMIS  scheduling  program  attempts 
to  schedule  all  tasks  that  are  to  be  conducted  in  the  same 
facility  at  approximately  the  same  time.  Also,  tasks 
involving  the  same  requirement  implementation  units  (e.g., 
the  same  hazard,  job  class,  organizational  unit,  etc.) 
will  be  scheduled  at  approximately  the  same  time,  if 
possible. 

Scheduling  tasks  so  that  they  are  started  as  early  as 
possible  and  end  before  the  due  date  for  the  task  (if 
any) . 

Scheduling  tasks  so  that  there  are  the  lowest  number  of 
interruptions  (e.g.,  breaks  for  lunch,  etc.)  in  the 
execution  of  the  task. 

Scheduling  tasks  in  accordance  with  the  preferred  time  use 
of  the  performer  of  the  task.  The  OHMIS  program  allows 
employees  who  will  be  performing  tasks  (e.g.,  occupational 
health  nurses,  industrial  hygiene  specialists,  etc.)  to 
specify  their  preferred  use  of  their  time.  For  example, 
if  a  performer  wishes  to  conduct  industrial  hygiene 
surveys  or  other  field  work  on  Mondays,  Wednesdays  and 
Fridays  and  conduct  office/paper  work  on  Tuesdays  and 
Thursdays,  this  can  be  specified  and  the  OHMIS  program 
will  attempt  to  schedule  the  tasks  in  accordance  with 
these  preferences. 

As  may  be  apparent,  there  may  be  conflicts  in  the  above  criteria  for 
scheduling  tasks.  For  example,  there  may  b^  no  time  available  (among 
persons  qualified  to  perform  a  task)  that  the  type  of  time  use  that 
is  needed  for  a  task,  except  time  after  the  due  date  for  the  task. 

The  conflict,  in  this  example,  would  be  whether  the  program  should 
schedule  the  task  after  the  due  date  or  schedule  the  task  not  in 
accordance  with  the  preferred  time  use.  Because  of  these  conflicts, 
the  OHMIS  scheduling  program  "optimize"  tne  scheduling  of  tasks.  This 
is  done  by  reviewing  all  options  for  scheduling  a  particular  task  >nd 
determining  which  option  has  the  best  characteristics  according  to 
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the  priority  given  to  each  of  the  scheduling  selection  criteria.  This 
means  that  the  program  may  make  several  "tries"  to  schedule  a  task 
before  it  "finds"  the  best  scheduling  option. 

SUMMARY  OF  SUBFUNCTIONS 

The  following  are  the  subfunctions  to  be  accomplished  under  this  OHMIS 
function: 


1.  The  program  identifies  a  series  of  time  slots  that  are 
available  for  scheduling  a  task.  It  then  determines  what 
are  the  character istics  of  these  time  slots  (e.g.,  dates, 
preferred  time  use,  etc.).  The  program  then  evaluates 
these  time  slots  characteristics  to  determine  if  they  meet 
the  criteria  for  a  "ideal"  scheduling  option.  If  they  do, 
this  scheduling  option  is  used.  If  not,  the  program 
continues  to  look  for  other  scheduling  options  until  an 
ideal  option  is  found  or  until  all  options  have  been 
exhausted.  At  that  point,  the  best  of  the  scheduling 
options  identified  is  chosen. 

2.  The  program  generates  Scheduling  Notices  (015)  informing 
participates  in  the  task  of  the  date  and  time  for  the 
task. 

TRIGGERING  STEPS  IN  THIS  FUNCTION:  None 


I 

I 

I 

I 
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Begin  generation  of  specific  task  scheduling  data  (DS24)  for  the  tasks 
that  need  to  be  scheduled  and  have  not  been  scheduled  before.  Compile 
a  list  of  all  tasks  that  currently  need  to  be  scheduled  for  the  OHMIS 
service  area  from  the  list  of  tasks  that  need  to  be  scheduled  (DL35), 
the  list  of  tasks  that  previously  could  not  be  scheduled  ( DL 31 )  and 
tne  tasks  that  have  been  previously  identified  (in  the  rescheduling 
Function,  i.e.,  Function  F4B)  as  needing  to  be  rescheduled  (DL39). 

PREVIOUS  STEP:  Step  F4A-1  follows  P40  of  Step  F1A-3. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  OHMIS  service  area  identifier  (ID10)  retained  in  P5 

of  Step  F1A-2 

R2:  Next  available  task  identif ier( s)  (1023) 

R3:  Next  available  weekly  schedule  identif ier( s)  (ID28) 

DS1:  Requirement  description  data 

DS3:  (Information  triggered)  Requirements  applicability 

data 

DS4:  Requirements  suspense  data,  i.e.,  date  triggered 

requirements  applicability  data 

DS5:  Requirements  implementation  data 

DS 17:  Allowable  limits  specification  data 

DS23:  Task  description  data 

DS25:  Facility  data  by  task  type 

DS28:  Contact  and  location  data 

DL31:  List  of  task  identifiers  (ID23)  for  tasks  that  cannot 
be  scheduled  by  OHMIS  service  area  ( ID 10 ) 

UL35:  List  of  requirement  implementation  identifiers  (ID9) 
for  requirements  having  tasks  that  need  to  be 
scheduled  by  OHMIS  service  area  (ID10) 
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OL 36 :  List  of  requirement  implementation  units  (or  sets  of 
units)  linked  to  their  corresponding  task  identifier 
(1023),  OHMIS  service  area  identifier  (1010)  and 
whether  the  task  is  an  'employee  transport'  type  of 
task 

OL37:  List  of  the  task  identifier  (ID23)  by  the  main 

facility  identifier  ( ID8)  in  which  the  task  will  take 
place  and  by  its  OHMIS  service  area  (ID10) 

DL38:  List  of  task  identifiers  (1023)  by  requirement 

implementation  identifier  (ID9)  and  by  OHMIS  service 
area  (1010) 

DL39:  List  of  task  identifiers  (1023)  for  tasks  that  need 
to  be  rescheduled  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Are  there  any  requirement  implementation  identifiers  ( 109) 

on  the  DL35  list  for  the  OHMIS  service  area  (ID10)  from 
Rl?  Yes  =  P2;  No  =  P12 

P2:  Put  the  ID9s  on  the  DL35  list  for  the  ID10  from  Rl  on  a 

temporary  list  called  the  P2  list. 

FN1:  FOR  each  109  on  the  P2  list: 

P3:  Locate  the  DS5  data  corresponding  to  the  109;  locate  the 

requirement  identifier  (ID6)  on  this  0S5  data;  locate  the 
DS1  data  corresponding  to  this  ID6;  locate  the  task  type 
code  (CT8)  on  this  0S1  data;  locate  the  DS23  data 
corresponding  to  this  CT8.  Also  locate  the  requirement 
application  identifier  (ID5)  on  the  DS5  data  and  locate 
the  requirement  applicability  data  (DS3,  DS4  or  DS17) 
correspond ing  to  this  105.  Also  identify  the  DS25  data, 
if  any,  corresponding  to  the  CT8  identified  above. 

P4:  Using  the  DS25  data  and  the  DS23  data  from  P3  for  this 

iteration  of  FNl,  generate  a  set  of  DS24  data.  Assign  the 
task  identifier  (1023)  from  R2.  The  date  the  DS24  data 
was  generated  should  be  the  same  as  the  date  that  the  DS5 
data  from  P3  for  this  iteration  of  FNl  was  generated.  The 
OHMIS  service  area  identifier  (ID10)  and  the  requirement 
implementation  units  come  from  the  DS5  data  from  P3.  The 
task  type  code  (CT8),  time  use  code  (CT11)  and  standard 
time  slots  required  to  complete  the  task  are  from  the  DS23 
data  from  P3  for  this  iteration  of  FNl.  The  user 
specified  time  slots  required  to  complete  the  task  should 
be  the  same  as  the  standard  time  slots  required  to 
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complete  the  task  at  this  point  in  the  program  (because 
the  user  has  not  yet  specified  any  difference  between  the 
standard  time  slots  required  and  the  user  specified  time 
slots  required).  The  ID9  assigned  to  the  DS24  data  should 
be  the  109  for  this  iteration  of  FNl.  Whether  the  task  is 
for  a  'requirement*  that  is  mandatory  or  a  recommendation 
is  from  the  0S2  data  from  P3.  The  due  date  and  whether 
the  task  was  triggered  by  a  Reminder  Notice  type  of 
suspense  requirement  is  from  the  DS4  data  from  P3  of  this 
iteration  of  FNl,  if  this  task  was  triggered  by  suspense 
type  (DS4)  requirement  applicability  data.  If  the 
requirement  was  not  a  DS4-triggered  requirement,  the  due 
date  is  from  the  DS23  data  from  P3.  The  facility 
identifier  (108)  is  from  the  0S25  data  from  P3,  if  any; 
or,  it  is  the  same  as  the  ID8  that  is  one  of  the 
requirement  implementation  units  for  the  task,  if  one  of 
the  requirement  implementation  units  is  a  facility;  or,  it 
is  from  the  DS28  data  for  the  employee  job  class  or 
organizational  unit  that  is  one  of  the  requirement 
implementation  units  for  the  task,  if  any;  or,  if  none  of 
these  sources  are  available,  this  field  is  left  blank.  If 
the  DS28  data  indicates  that  there  are  standard  (weekly 
schedule)  restrictions  on  the  time  that  this  task  can  be 
scheduled,  generate  a  set  of  DS26  data  based  on  the  data 
in  the  DS28  data  located  in  P3  and  place  the  weekly 
schedule  identifier  (1028)  for  this  new  DS26  data,  i.e., 
the  ID28  from  R3,  on  the  new  DS24  data.  Answer  the 
question  about  whether  the  task  has  been  scheduled  as 
'No'.  Put  a  code  of  ' D '  (not  yet  attempted  to  schedule) 
in  answer  to  the  question  on  the  DS24  data  about  whether 
this  task  has  been  scheduled.  The  rest  of  the  data 
elements  on  the  new  DS24  data  are  left  blank  at  this  time. 

P5:  Remove  the  ID9  for  this  iteration  of  FNl  from  the  DL35 

list. 

P6:  Add  the  ID23  and  the  1010  assigned  to  the  DS24  data 

generated  in  P4  and  the  ID9  for  this  iteration  of  FNl  to 
the  DL38  list. 

P7:  Determine  from  the  DS23  data  from  P3  for  this  iteration  of 

FNl  whether  this  task  is  an  'employee  transport'  type  of 
task.  Add  the  ID23  and  the  ID 10  assigned  to  the  DS24  data 
generated  in  P4,  the  requirement  implementation  units,  and 
whether  the  task  is  an  'employee  transport*  type  of  task 
(answer:  Yes/No)  in  the  new  DS24  data  generated  in  P4  to 
the  D136  list. 

P8:  Add  the  CT8  from  P3  and  the  ID23  assigned  to  the  new  DS24 

data  to  the  D55  data  located  in  P3. 


■  •  I-  ,  . 
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P9:  Add  the  ID23,  ID10  and  ID8,  if  any,  assigned  to  the  new 

DS24  data  generated  in  P4  to  the  DL37  list. 

P10:  Put  the  ID23  assigned  in  this  iteration  of  FNl  on  a 

temporary  list  called  the  P10  list.  Retain  this  list 
throughout  Function  F4A. 

PI 1 :  NEXT  FNl;  end  of  FNl,  GO  TO  P12. 

P12:  Are  there  any  task  identifiers  (ID23)  on  the  DL31  list  for 

the  OHMIS  service  area  (ID10)  from  Rl?  Yes  =  P13;  No  = 

P14 

P13:  Add  each  of  the  ID23s  on  the  DL31  list  for  the  ID10  from 

Rl  to  the  P10  list. 

P14:  Are  there  any  1023s  on  the  DL39  list  for  the  I DIO  for  the 

OHMIS  service  area  (1010)  from  Rl?  Yes  =  P15 ;  No  =  P21 

P 15 :  Put  the  1023s  on  the  0L39  list  for  the  I DIO  from  Rl  on 

the  P10  list. 

P16:  GO  TO  PI  of  Step  F4A-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

0S24:  Specific  task  scheduling  data 

DS26:  Regular  weekly  schedule  availability  data  (for  the  regular 
weekly  schedule  during  which  a  task  cannot  be  scheduled, 
i.e.,  the  regular  weekly  restrictions  for  the  task) 
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For  each  of  the  tasks  identified  in  Step  F4A-1  as  currently  needing  to 
be  scheduled,  identify  those  that  are  scheduleable,  i.e.,  those  for 
which  there  are  persons  qualified  to  perform  the  task  in  the  OHMIS 
service  from  which  the  task  originated.  For  the  scheduleable  task, 
determine  if  the  task  is  an  'employee  transport1  type  of  task.  If 
'Yes',  continue.  If  'No',  go  to  Step  F4A-6. 

Employee  transport  tasks  are  tasks  that  require  "transporting"  an 
employee  from  his/her  regular  work  site  to  perform  the  task.  An 
example  of  such  a  task  is  a  task  involving  medical  surveillance  of  an 
employee.  In  order  to  reduce  the  number  of  times  that  employees  are 
"transported".  Function  4A  attempts  to  schedule  all  employee  transport 
tasks  for  the  same  employee  at  the  same  time.  This  involves 
identifying  the  groups  of  tasks  that  include:  1)  all  employee 
transport  tasks  that  are  currently  being  scheduled  (i.e.,  those 
identified  in  Step  F4A-1)  that  are  for  the  same  employee;  2)  all 
employee  transport  tasks  that  have  already  been  scheduled  for  the 
same  employee;  and,  3)  all  future  OHM I S  requirements  that  will 
result  in  the  scheduling  of  an  employee  transport  task,  i.e.,  all 
future  scheduled  tasks  for  the  same  employee. 

Step  F4A-2  generates  temporary  lists  (referred  to  P24  lists).  Each 
list  contains  the  information  about  the  set  of  tasks  that  all  belong 
to  the  same  group,  i.e.,  the  set  of  employee  transport  tasks  for  the 
same  employee  that  are  either  currently  being  scheduled,  already 
scheduled  or  will  be  scheduled  in  the  near  future  (within  90  days). 

The  scheduling  of  the  group  of  tasks  on  the  P24  list  is  done  in  Step 
F4A-3,  if  the  group  includes  already  scheduled  tasks;  in  Step  F4A-5, 
if  there  is  only  one  tas*  in  the  group  (i.e.,  there  are  no  "already 
scheduled"  or  "future  scheduled"  employee  transport  tasks  for  the  same 
task  that  is  currently  being  scheduled;  and.,  therefore,  it  is  not 
necessary  to  schedule  the  task  next  to  any  other  task);  or,  in  Step 
F4A-4,  for  all  other  groups  of  tasks. 

PREVIOUS  STEP:  Step  F4A-2  follows  P16  of  Step  F4A-1. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrievals: 

Rl:  The  list  of  task  identifiers  (ID23)  for  the  tasks 

that  currently  need  to  be  scheduled;  from  the  list 
generated  in  P10  of  Step  F4A-1 

R2:  Current  date 
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R3:  The  date  that  is  one  quarter  (90  days)  later  than  the 

current  date  (R2) 

DS1:  Requirement  description  data 

DS 4:  Requirements  suspense  data,  i.e.,  date  triggered 

requirements  applicability  data 

DS5:  Requirements  implementation  data 

DS23:  Task  description  data 

DS24:  Specific  task  scheduling  data 

DS2S:  Facility  data  by  task  type 

DS28:  Contact  and  location  data 

DL31:  List  of  task  identifiers  (1D23)  for  tasks  that  cannot 
be  scheduled  by  OHMIS  service  area  ( ID 10 ) 

DL32:  List  of  the  employee  identifier  (ID4)  that  is  one  of 
the  requirement  implementation  units  by  the 
corresponding  requirement  application  identifier 
(ID5)  and  OHMIS  service  area  identifier  (ID10),  for 
those  105 s  that  identify  requirements  suspense  data 
sets  (DS4)  that  will  trigger  an  'employee  transport1 
type  of  task 

DL34:  List  of  qualified  employee  identifiers  (104)  by  task 
type  (CT8)  and  by  OHMIS  service  area  (ID10) 

0L36:  List  of  requirement  implementation  units  (or  set  of 
units)  linked  to  their  corresponding  task  identifier 
(ID23),  OHMIS  service  area  identifier  ( 1 0 10 )  and 
whether  the  task  is  an  'employee  transport'  type  of 
task 

PROCESSING  (P  -  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Generate  a  copy  of  the  R1  list,  i.e.,  the  list  of  tasks 

that  are  to  be  scheduled  in  this  execution  of  Function 
F4A.  This  is  called  the  PI  list.  Retain  the  PI  list 
throughout  Step  F4A-2. 

F N 1 :  FOR  each  of  the  task  identifiers  (ID23)  on  the  PI  list: 

P2:  Locate  the  DS24  data  corresponding  to  the  1023.  Locate 

the  task  type  code  (CT8)  and  the  OHMIS  service  area 
identifier  (1010)  on  this  0S24  data. 
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P3:  Are  there  any  employee  identifiers  (ID4)  on  the  DL 34  list 

for  the  CT8  and  I DIO  from  P2?  Yes  =  P 9 ;  No  (i.e.,  this 
task  is  not  scheduleable,  because  there  are  no  persons 
qualified  to  perform  the  task  in  the  OHMIS  service  area  in 
which  the  task  originated)  =  P4 

P4:  Remove  the  ID23  for  this  iteration  of  FNl  from  the  PI 

list.  Fill  in  the  DS24  data  from  P2  to  indicate  that  this 
task  cannot  be  scheduled  because  of  the  lack  of  qualified 
persons.  This  is  done  by  entering  the  code  of  'A'  on  the 
DS24  data. 

P5:  Place  the  ID23  for  this  iteration  of  FNl  on  a  list  called 

the  P5  list.  Retain  the  P5  list  throughout  Function  F4A. 

P6:  Is  the  ID23  for  this  iteration  of  FNl  and  the  I DIO  from  P2 

on  the  DL31  list?  Yes  =  P 9 ;  No  =  P7 

P7:  Add  the  1023  for  this  iteration  of  FNl  and  the  ID10  from 

P2  to  the  DL31  list. 

P8:  GO  TO  P13  (next  FNl). 

P9:  Locate  the  DS23  data  for  the  CT8  from  P2. 

P10:  Does  the  0S23  data  from  P9  indicate  that  this  is  an 

‘employee  transport'  task?  Yes  =  P13  (next  FNl);  No  =  Pll 

Pll:  Remove  the  ID23  for  this  iteration  of  FNl  from  the  PI 

1  ist. 

P12:  Add  the  1023  for  this  iteration  of  FNl  to  the  list,  called 

the  P12  list.  Retain  the  P12  list  throughout  Function  4A. 

P13:  NEXT  FNl;  end  of  FNl,  GO  TO  P14. 

P14:  Are  there  any  1023s  still  on  the  PI  list?  Yes  =  P20;  No  = 

Plb 

P15:  Are  there  any  ID23s  on  the  P12  list?  Yes  =  P16;  No  =  P17 

P16:  GO  TO  PI  of  Step  F4A-6. 

P17:  End  of  Function  F4A;  close  out  and  erase  all  temporary 

lists  and  records  from  Function  F4A. 

P18:  GO  TO  P41  of  Step  F1A-3. 

P19:  Erase  the  PI  list.  GO  TO  FN2  (P22). 

Copy  the  I D2 3 s  remaining  on  the  Pi  list  onto  a  list  called 
the  P20  list.  The  P20  list  is  the  list  of  scheduleable 
employee  transport  tasks  that  currently  need  to  be 


P20 


STEP  F4A-2 


scheduled,  i.e.,  that  need  to  be  scheduled  in  this 
execution  of  Function  4A. 

P21:  Retain  the  P20  list  throughout  Step  F4A-2.  60  TO  P19. 

FN2:  FOR  each  1023  on  the  P20  list: 


P22:  Locate  the  DS24  data  corresponding  to  the  ID23.  Locate 

the  task  type  code  (CT8)  on  this  DS24  data.  Locate  the 
DS23  data  corresponding  to  this  CT8.  Also,  locate  the 
requirement  implementation  identifier  (ID9)  on  the  DS24 
data;  locate  the  DS5  data  corresponding  to  this  ID9; 
locate  the  requirement  application  identifier  (ID5)  on 
this  DS5  data. 

P23:  Using  the  0S24  data  from  P22,  identify  the  OHMIS  service 

area  identifier  (1010),  requirement  implementation  unit(s) 
(including  the  employee  identifier  (ID4)  that  must  be  one 
of  the  requirement  implementation  units,  because  this  is 
an  ‘employee  transport1  type  of  task),  the  time  use  code 
(CT11),  the  f  cility  identifier  (108),  if  known,  and  the 
user  specified  number  of  time  slots  required  to  complete 
the  task,  for  the  task  in  this  iteration  of  FN 2 . 

P24:  Begin  generating  a  temporary  list,  called  the  P24  list. 

(Generate  a  new  such  P24  list  for  each  FN 2 ;  do  not  erase 
previous  P24  lists  generated  in  other  iterations  of  FN2; 
retain  the  P24  lists  throughout  Function  4A. )  Label  this 
P24  list  with  the  1023  from  this  iteration  of  FN2.  Each 
entry  on  the  P24  list  will  consist  of  the  following  11 
data  elements: 

(1)  A  task  identifier  (ID23). 

(2)  A  code  (1-3)  indicating  whether  this  task  is  one 
currently  being  scheduled  (Lode  '1'),  one  already 
scheduled  (Code  '2'),  or  one  that  will  be  scheduled 
in  the  future  (Code  ' 3 ' ) . 

(3)  A  requirement  application  identifier  (ID5).  If  the 
task  is  to  be  scheduled  in  the  future  (Code  '3'  in 
data  element  (2)),  leave  data  element  (1)  blank  and 
put  in  data  element  (3),  the  105  for  the  DS4  data 
that  will  eventually  trigger  the  task  (i.e.,  the  105 
from  DL32).  For  the  other  tasks  (i.e.,  for  the 
currently  being  scheduled  tasks  and  the  already 
scheduled  tasks  (Code  *  1 1  and  '2',  respectively  in 
data  element  (2))  put  in  data  element  (3)  the  1D5  of 
the  requirement  applicability  data  (DS3,  DS4,  or 
0S17)  that  triggered  tne  requirement  that  initiated 
tne  task.  This  ID5  is  from  the  D55  data  that  is 
identified  by  the  requirement  implementation 
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identifier  (109)  that  is  on  the  DS24  data  identified 
by  the  1023  in  data  element  (1). 

(4)  Limiting  dates  and  times,  if  any,  for  the  task: 

(a)  The  due  date,  if  any,  for  the  task.  This  is 
from  the  DS24  data  correspond ing  to  the  ID23  in 
data  element  (1)  (for  currently  being  scheduled 
and  already  scheduled  tasks,  i.e.,  code  *1'  and 
'2'  in  data  element  (2))  or  from  the  DS4  data 
referenced  by  the  IDS  in  data  element  (3)  (for 
future  scheduled  (code  '3'  in  data  element  (2)) 
tasks) . 

(b)  Whether  there  are  any  restrictions  on  the 
task;  if  so,  whether  the  restrictions  are 
standard,  special  or  both;  and,  the  weekly 
schedule  identifier  (1028)  identifying  the  DS26 
for  the  standard  restrictions,  if  any,  from  the 
DS24  data  for  code  '1'  and  code  '2'  tasks. 

Code  '3'  tasks  (future  scheduled)  can  only  have 
standard  restrictions.  The  ID23  for  the 
standard  restrictions,  if  any,  is  from  the  DS28 
data,  if  any,  for  the  employee  identifier  (104) 
that  is  one  of  the  requirement  implementation 
units  for  the  task.  (Requirement 
implementation  units  for  future  scheduled  tasks 
are  from  the  0S4  data  that  is  identified  by  the 
105  in  data  element  (3)) . 

(5)  The  QHMIS  service  area  identifier  ( I  DIP )  for  the 
task.  From  the  0S24  data  correspond ing  to  the  1023 
in  data  element  (1)  for  tasks  with  code  'l1  and  '2' 
in  data  element  (2).  From  the  DS4  data  that  will 
trigger  the  task  (i.e.,  the  DS4  data  with  the  ID5  in 
data  element  (3))  for  future  scheduled  tasks  (code 
'3' )  in  data  element  (2)) . 

(6)  The  task  type  code  (CT8)  for  the  task.  From  the 
0S24  data  for  the  1023  in  data  element  (1)  for 
currently  scheduled  and  already  scheduled  tasks. 

From  the  051  data  for  the  requirement  identifier 
(106)  that  is  on  the  DS4  data  that  will  eventually 
trigger  the  task  (as  identified  by  the  ID5  in  data 
element  (3))  for  future  scheduled  tasks. 

(7)  The  time  use  code  (CU1)  for  the  task.  From  the 
DS23  data  corresponding  to  the  task  type  code  (CT8) 
in  data  element  (6). 

\3)  The  facility  identifier  (IDS)  in  which  the  task 

will  be  conducted,  if  known.  From  the  0S24  dat3  for 
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the  ID23  in  data  element  (1)  for  currently  being 
scheduled  and  already  scheduled  tasks.  For  future 
scheduled  tasks,  the  108  is  crom  the  DS25  data  for 
the  CT8)  from  DE  (6);  or  the  ID8  that  is  one  of  the 
requirement  implementation  units  for  the  task;  or, 
the  0S28  data  for  the  employee  identifier  (ID4)  that 
is  one  of  the  requirement  implementation  units  for 
the  task.  (Requirement  implementation  units  for 
future  scheduled  tasks  are  from  the  DS4  data  that  is 
identified  by  the  ID5  in  data  element  (3)). 

(9)  The  number  of  time  slots  required  to  complete  the 
task .  For  currently  being  scheduled  tasks  (code  '1' 
in  data  element  (2))  use  the  user  specified  number 
of  time  slots  required  to  complete  the  task  from  the 
DS24  data  for  the  ID23  in  data  element  (1).  For  the 
future  scheduled  task  (code  '3'  in  data  element  (3)) 
use  the  standard  number  of  time  slots  required  to 
complete  the  task  from  the  DS23  data  corresponding  to 
the  task  type  code  (CT8)  in  data  element  (6). 

(10)  If  the  task  is  an  already  scheduled  task  (code  '2'  in 
data  element  (2)),  the  following  5  additional  data 
elements,  all  from  the  DS 24  data  corresponding  to  the 
ID23  in  data  element  (1),  snould  be  included  on  the 
P24  list: 

(a)  The  time  slot  information  for  the  start  time 
for  the  task.  Time  slot  information  consists 
of  6  parts:  (1)  a  monthly  schedule  identifier 
(ID27),  (2)  year,  (3)  month  (1-12),  (4'  date 
(1-31),  (5)  time  slot  number  (number  from  ' 1 ' 
to  '96'  indicating  the  quarter  of  an  hour 
period  during  a  day),  and  (6)  day  of  the  week 
(1-7).  (Note:  Parts  (2),  (3)  and  (6)  are  from 
the  DS27  data  correspond  ing  to  the  ID27  in  part 

(D). 

(b)  The  time  slot  information  for  the  end  time 
for  the  task. 

(c)  Whether  the  task  was  scheduled  within  the  due 
date  for  the  task 


(d)  Time  use  code  (CT11)  under  which  the  task  was 
schedu led 

(e)  Whether  the  user  specified  the  schedule  for 
tiu-  task 


(11)  A  code  (1-99)  indicating  to  which  set  of  qualified 
users  wno  can  perform  the  task  the  task  belongs. 
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Arbitrary  number,  temporarily  assigned,  in  order  to 
group  the  tasks  on  the  P24  list  by  common  sets  of 
user(s)  qualified  to  perform  the  task. 

P25:  Put  the  label  of  the  P24  list  (i.e.,  the  ID23  for  this 

iteration  of  FN 2 )  on  a  temporary  list,  called  the  P25 
list.  This  is  the  list  of  labels  for  all  P24  lists.  The 
P24  lists  are  the  groups  of  employee  transport  tasks  that 
are  for  the  same  employee.  Each  P24  list  consists  of  at 
least  one  task  that  is  currently  being  scheduled.  The 
list  may  also  contain  other  employee  transport  tasks  for 
the  same  employee  that  are  currently  being  scheduled, 
already  scheduled,  or  going  to  be  scheduled  in  the  near 
future.  The  P24  lists  are  used  to  enable  scheduling 
employee  transport  tasks  for  the  same  employee  as  a  group, 
i.e.,  to  enable  scheduling  all  employee  transport  tasks 
for  an  employee  at  the  same  time,  if  possible. 

P26:  Put  the  information  about  the  task  for  this  iteration  of 

FN2  as  the  first  entry  (i.e.,  the  first  set  of  11  data 
elements)  on  the  P24  list  generated  for  this  iteration  of 
FN2.  The  data  element  (1)  should  be  the  ID23  for  this 
iteration  of  FN2.  Data  element  (2)  should  be  the  code  ‘ 1 ‘ 
(currently  being  scheduled).  The  task  type  code  (CT8), 
i.e.,  data  element  (6)  and  the  requirement  application 
identifier  (ID5),  i.e.,  data  element  (3)  are  from  P22. 
Leave  data  element  (10)  and  (11)  blank.  The  rest  of  the 
data  elements  on  the  P24  list  entry  come  from  the  data 
located  in  P23. 

FN2.1:  FOR  each  ID23  on  the  DL36  list: 

P27:  Is  this  ID23  the  same  as  the  ID23  for  this  iteration  of 

FiV2  (i.e.,  there  is  already  a  P24  list  entry  for  this 
task)?  Yes  =  P35;  No  =  P28 

P28:  Is  the  1023  for  this  iteration  of  FN2.1  on  the  P5  list 

(i.e.,  the  list  of  tasks  newly  determined  (in  this 
execution  of  Function  4A)  to  be  unscheduleable,  because 
there  are  no  persons  qualified  to  perform  the  task  in  the 
OHM  I S  service  area  in  which  the  task  originated)?  Yes  = 
P39  (next  FN2.1);  No  =  P29 

P29:  Is  the  1023  for  this  iteration  of  FN2.1  for  an  employee 

transport  type  of  task?  (Note:  This  information  is  given 
on  the  DL36  list  entry.)  Yes  =  P3U;  No  =  P39  (next  FN2.1) 

Does  the  1023  for  this  iteration  of  FN2.1  have  the  same 
OH i4 IS  service  area  (ID1U)  and  have  the  same  employee 
identifier  (104)  as  one  ot  its  requirement  implementation 
units  (as  shown  on  the  DL36  list  entry)  as  the  task  in 


P30 : 


STEP  F4A-2 


this  iteration  of  FN2  (as  identified  in  P 23 ) ?  Yes  =  P31; 
No  =  P39  (next  FN2.1) 

P31:  Locate  the  DS24  data  corresponding  to  the  ID23  in  this 

iteration  of  FN2.1.  Identify  the  task  type  code  (CT8)  on 
this  DS24  data.  Locate  the  DS23  data  for  this  CT8.  Also 
locate  the  requirement  implementation  identifier  ( ID9)  on 
the  DS24  data;  locate  the  DS5  data  corresponding  to  this 
ID9;  locate  the  requirement  application  identifier  (ID5) 
on  this  DS5  data.  Also,  use  this  DS24  data  to  identify 
the  OHMIS  service  area  (ID10),  the  requirement 
implementation  units  (including  the  employee  identifier 
(ID4)),  the  time  use  code  (CT11),  due  date  (if  any), 
facility  identifier  (108)  (if  known)  and  the  user 
specified  number  of  time  slots  required  to  complete  the 
task,  for  the  task  in  this  iteration  of  FN2.1. 

P32:  Put  the  information  about  the  task  in  this  iteration  of 

FN2.1  onto  the  most  recently  generated  P24  list  (i.e.,  the 
P24  list  generated  in  this  iteration  of  FN2).  Data 
element  (1)  on  the  P24  list  is  the  ID23  for  this  iteration 
of  FN2.1.  Leave  data  elements  (2),  (10),  and  (11)  blank. 
The  rest  of  the  data  elements  are  from  P31. 

P33:  Is  the  1023  for  this  iteration  of  FN2.1  on  the  P20  list? 

Yes  (i.e.,  this  task  is  currently  being  scheduled)  =  P34; 
No  =  P37 

P34:  Fill  data  element  (2)  of  the  last  entry  made  (i.e.,  the 

entry  made  in  this  iteration  of  FN2.1)  to  the  P24  list  for 
this  iteration  of  FN2  with  the  code  '1'  (currently  being 
schedu led ) . 

P 3b :  Erase  the  1023  for  this  iteration  of  FN2.1  from  the  P20 

list. 

P36:  GO  TO  P39  (next  FN2.1). 

P37:  Fill  data  element  (2)  of  the  last  entry  made  (i.e.,  the 

entry  made  in  this  iteration  of  FN2.1)  to  the  P24  list  for 
this  iteration  of  FN2  with  the  code  '2'  (already 
scheduled ) . 

P38:  Fill  in  data  element  (10)  of  the  last  entry  made  (i.e., 

the  entry  made  in  this  iteration  of  FN2.1)  to  the  P24  list 
for  this  iteration  of  FN2.  Use  the  DS24  data  obtained  in 
P31 . 

P  39:  NEXT  FN2.1,  end  of  FN2.1,  GO  TO  FN2.2  (P40). 

F N 2 . 2 :  FOR  each  of  the  requirement  application  identifiers 
( 105 )  on  tne  0L32  list: 
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P40:  Are  the  employee  identifier  (ID4)  and  the  IDIO  for  the 

DL32  list  entry  for  this  iteration  of  FN 2.2  (as  shown  on 
the  DL32  list  entry)  the  same  as  the  ID4  and  IDIO  for  this 
iteration  of  FN2  (as  identified  in  P23 ) ?  Yes  =  P41;  No  = 
P47  (next  FN2.2) 

P41:  Is  the  ID5  for  this  iteration  of  FN2.2  contained  in  data 

element  (3)  on  one  of  the  entries  on  the  P24  list  for  this 
iteration  of  FN2?  Yes  =  P47  (next  FN2.2);  No  =  P42 

P42:  Locate  the  DS4  data  corresponding  to  the  ID5  for  this 

iteration  of  FN2.2.  Identify  the  requirement 
implementation  unit(s)  and  OHMIS  service  area  identifier 
(IDIO)  on  this  DS4  data. 

P43:  Examine  the  'next  suspense  date'  on  the  DS4  data  from  P42. 

Derive  the  date  that  is  equal  to  the  'prior  notification 
time',  if  any,  on  the  DS4  data  added  to  the  'next  suspense 
date'.  The  date  thus  generated  is  the  due  date  for  the 
requirement  (and  task)  triggered  by  this  DS4  data. 

Is  this  due  date  calculated  in  P43  equal  to  or  earlier 
than  the  R3  date,  i.e.,  is  the  task  for  this  DS4  data 
going  to  be  due  within  the  next  90  days?  Yes  (i.e.,  the 
task  for  this  DS4  data  is  going  to  be  triggered  in  the 
near  future  and  therefore,  this  task  is  considered  a 
'future  scheduled  task*  and,  because  it  is  an  'employee 
transport'  task  (otherwise  it  would  not  have  been  on  the 
DL32  list),  it  should,  if  possible,  be  scheduled  with  the 
other  tasks  for  the  same  employee  that  are  currently  being 
scheduled)  =  P45;  No  =  P47  (next  FN2.2) 

P 44 :  Identify  the  OHMIS  service  area  identifier  (IDIO)  on  the 

DS4  data  from  P42.  Also  identify  the  requirement 
identifier  (ID6)  on  the  DS4  data  from  P42.  Locate  the  DS1 
data  corresponding  to  this  ID6.  Identify  the  task  type 
code  (CT8)  on  this  set  of  DS1  data.  Are  there  any 
employee  identifiers  (ID4)  on  the  DL31  list  for  this  IDIO 
and  CT 8?  Yes  =  P45;  No  =  P47  (next  FN2.2) 

P45:  Locate  the  DS23  data  for  the  CT8  identified  in  P44. 

Locate  the  DS25  data,  if  any,  correspond ing  to  the  CT8; 
identify  the  facility  identifier  ( ID8)  on  this  DS25  data. 
If  no  DS25  data,  locate  the  facility  identifier  (ID8),  if 
any,  that  may  be  one  of  the  requirement  implementation 
units  located  in  P42.  If  the  requirement  implementation 
units  do  not  include  an  ID8,  locate  the  DS28  data,  if  any, 
for  the  employee  identifier  (ID4)  that  must  be  one  of 
these  units  and  locate  the  IDS  on  this  DS28  data.  If  no 
DS28  data,  the  108  is  not  known  for  the  task  that  will  be 
triggered  by  the  requirement  applicability  (105)  in  this 
iteration  of  FN 2.2. 
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P46:  Put  the  information  about  the  requirement  applicability 

(105)  in  this  iteration  of  FN2.2  onto  the  most  recently 
generated  P24  list  (i.e.,  the  P24  list  generated  in  this 
iteration  of  FN2).  Data  element  (1)  should  be  left  blank; 
at  this  point  this  future  schedule  "task’’,  has  not  yet 
become  a  task  (i.e.,  there  is  no  DS24  data  and  therefore 
no  task  identifier  (1023)  for  the  task;  at  this  point,  the 
future  scheduled  "task"  is  simply  a  specif ication  for 
determining  the  applicability  of  a  requirement  (i.e.,  DS4 
data  with  a  requirement  application  identifier  (105))  from 
which  the  task  data  (0S24)  will  be  generated.  Data 
element  (2)  should  be  filled  with  the  code  '3'  (future 
scheduled  task).  Data  element  (3)  is  the  105  for  this 
iteration  of  FN2.2.  The  due  date  (data  element  (4))  is 
from  P43.  The  OHMIS  service  area  identifier  (ID10),  i.e., 
data  element  (5),  is  from  P44.  The  task  type  code  (CT8), 
i.e.,  data  element  (6),  is  from  P44.  The  time  use  code 
(CT11),  i.e.,  data  element  (7)  and  the  st  indard  number 
of  time  slots  required  to  complete  this  task,  i.e.,  data 
element  (9),  are  from  the  DS23  data  located  in  P45.  Data 
elements  (10)  and  (11)  are  left  blank. 

P47:  NEXT  FN2.2;  end  of  FN2.2,  GO  TO  P48. 

P48:  NEXT  FN2;  end  of  FN2,  GO  TO  FN3  (P49). 

FN3:  FOR  each  ID23  on  the  P25  list  (i.e.  the  list  of  labels 

for  P24  1 ists) : 

P49:  Locate  the  P24  list  with  the  1023  for  this  iteration  of 

FN3  as  its  label . 

P50:  Store  the  value  '1'. 

FN3.1:  FOR  each  entry  (i.e.,  each  set  of  11  data  elements  on  a 
task)  on  the  P24  list  from  P49: 

P51:  Identify  data  element  (6),  i.e.,  the  task  type  code  (CT8) 

on  the  entry.  Also  identify  data  element  (5),  i.e.,  the 

OHMIS  service  area  identifier  (1010)  on  the  entry. 

P52:  Using  the  0L34  list,  identify  all  of  the  employee 

identifiers  (104)  for  the  same  CT8  and  1010  as  those 
identified  in  P51 .  Put  these  ID4s  on  a  temporary  list 
called  the  P52  list. 

P53:  Are  there  any  P54  temporary  lists?  Yes  =  FN3.1.1  (P60); 

No  =  P54 

P54:  Begin  generating  a  temporary  list,  called  the  P54  list. 

Retain  this  list  throughout  Step  F4A-2.  Generate  a  new 
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P54  list  each  time  P54  is  executed,  i.e.,  do  not  erase  the 
P54  lists  generated  in  previous  executions  of  P54.  Label 
this  P54  list  witn:  (1)  the  ID23  for  this  iteration  of 
FN3  and  (2)  the  value  stored  in  P50. 

P55:  Put  the  two-part  label  entered  on  the  P54  list  just 

generated  on  a  temporary  list,  called  the  P55  list. 

P56:  Add  the  ID4s  on  the  P52  list  to  the  P54  list  just 

generated. 

P57:  Fill  in  data  element  (11)  on  the  P24  list  entry  for  this 

iteration  of  FN 3  with  the  value  stored  in  P50. 

P58:  Add  '1'  to  the  value  stored  in  P50. 

P59:  Erase  the  P52  list. 

P60:  GO  TO  P66  (next  FN3.1). 

FN3.1.1  (from  P53):  FOR  each  of  the  two-part  labels  on  the  P55 
list: 

P61:  Locate  the  P54  list  corresponding  to  the  label. 

P62:  Are  the  ID4s  on  the  P54  list  from  P61  exactly  the  same  as 

the  ID4s  on  the  P52  list?  (Note:  The  ID4s  do  not  need 
to  be  in  the  same  order  on  both  lists;  it  is  only 
necessary  that  the  same  exact  ID4s  be  on  both  lists.)  Yes 
(i.e.,  the  same  persons  are  qualified  to  perform  the  task 
in  this  iteration  of  FN3.1  as  were  found  to  be  qualified 
to  do  one  or  more  other  tasks  on  the  P24  list  for  this 
iteration  of  FN3)  =  P63;  No  =  P65  (next  FN 3.1.1) 

P63:  Fill  in  data  element  (11)  on  the  P24  list  entry  for  this 

iteration  of  FN3.1  with  the  value  in  the  second  part  of 
the  two-part  label  that  is  this  iteration  of  FN3.1.1 
(i.e.,  the  value  obtained  in  P50). 

P64:  GO  TO  P59. 

P65:  NEXT  FN3.1.1;  end  of  FN3.1.1,  GO  TO  P54. 


P66:  (from  P60)  NEXT  FN3.1;  end  of  FN3.1,  GO  TO  P67. 


P67:  Is  there  more  than  one  entry  (i.e.,  set  of  11  data 

elements)  on  the  P24  list  from  P49?  Yes  (i.e.,  it  will  be 
necessary  to  attempt  to  schedule  multiple  employee 
transport  tasks  at  approximately  the  same  time  so  that  the 
employee  does  not  have  to  be  "transported"  more  than  once) 
=  P 70 ;  No  =  P68 
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P68:  Put  the  1023  for  this  iteration  of  FN3  on  a  temporary  list 

called  the  P68  list.  Retain  this  list  throughout  Function 
F4A.  The  P68  list  is  the  list  of  labels  of  P24  list  for 
P24  lists  in  which  there  is  only  one  task  on  the  P24  list. 
The  one  task  on  the  P24  lists  for  which  the  label  for  the 
P24  list  is  on  the  P68  list  must  be  a  'currently  being 
scheduled'  task  and  it  will  not  be  necessary  to  schedule 
tasks  in  groups  when  scheduling  these  tasks. 

P69:  GO  TO  P72. 

P70:  Examine  the  value  in  data  element  (2)  for  each  entry  (set 

of  li  data  elements)  on  the  P24  list  from  P49.  Is  the 
value  for  any  of  these  entries  a  '2'  (already  scheduled)? 
Yes  (i.e.,  it  will  be  necessary  to  attempt  to  schedule  all 
of  the  tasks  on  the  P24  list  next  to  an  already  scheduled 
task  so  that  the  employee  does  not  have  to  be 
"transported"  more  than  once)  =  P73  (next  FN3);  No  (i.e., 
all  of  the  tasks  on  the  P24  list  are  not  now  currently 
scheduled  (i.e.,  they  are  either  currently  being  scheduled 
in  this  execution  of  Function  F4A  or  are  future  scheduled 
tasks)  so  that  it  is  not  necessary  to  schedule  the  task 
next  to  a  particular  other  task)  =  P71 

P71:  Put  the  1023  for  this  iteration  of  FN3  on  a  list  called 

the  P71  list.  Retain  this  list  throughout  Function  F4A. 
The  P71  list  is  the  list  of  labels  for  the  P24  lists  that 
have  two  or  more  tasks  on  them  and  none  are  'already 
scheduled'  tasks.  The  tasks  must  include  at  least  one 
'currently  being  scheduled'  taskk.  The  tasks  may,  but  do 
not  necessarily,  include  'future  scheduled'  tasks. 

P 72 :  Remove  the  1023  for  this  iteration  of  FN3  from  the  P25 

list.  When  FN 3  is  completed,  the  P25  list  will  be  the 
list  of  labels  of  P24  lists  that  have  at  least  two  tasks 
on  them,  one  of  which  must  be  an  'already  scheduled1  task 
and  one  of  which  must  be  a  'currently  being  scheduled' 
task.  There  may  also  be  'future  scheduled'  tasks,  but 
this  is  not  necessary. 

P73:  NEXT  FN3;  end  of  FN3,  GO  TO  P74. 

P74:  Are  there  any  1023s  still  on  the  P25  list?  Yes  (i.e., 

there  are  employee  transport  tasks  that  need  to  be 
schedulea  next  to  an  already  scheduled  task  for  the  same 
employee)  =  P76;  No  =  P75 

Are  there  any  1023s  on  the  P71  list?  Yes  (i.e.,  there  are 
sets  of  employee  transport  tasks  that  need  to  be 
scheduled  as  a  group,  because  they  are  for  the  same 
employee,  but  for  which  there  is  no  already  scheduled  task 
next  to  which  the  tasks  need  to  be  scheduled)  -  P77;  No 
(i.e.,  the  remaining  tasks  to  be  scheduled  are  on  the  P68 


P  7b  : 
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list;  that  is,  they  are  employee  transport  tasks  that 
currently  need  to  be  scheduled,  but  they  do  not  need  to  be 
scheduled  next  to  any  other  task  because  there  are  no 
already  scheduled  or  future  scheduled  employee  transport 
tasks  for  the  same  employee  at  this  time)  =  P78 

P76 :  GO  TO  PI  of  Step  F4A-3. 

P77 :  GO  TO  PI  of  Step  F4A-4. 

P78:  GO  TO  PI  of  Step  F4A-5. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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In  this  Step,  the  groups  of  'employee  transport1  tasks  formed  in 
Step  F4A-2  that  contain  'already  scheduled1  are  scheduled. 

('Employee  transport'  tasks  are  those  requiring  bringing  the  employee 
participating  in  the  task  away  from  his  work  site,  such  as  tasks  that 
involve  providing  a  medical  examination  for  an  employee.)  Each  of  the 
groups  of  tasks  scheduled  in  Step  F4A-3  contains  at  least  one  'already 
scheduled'  task.  That  is,  the  group  contains  two  or  more  task 
involving  the  same  employee,  at  least  one  of  which  task  has  already 
been  scheduled.  Thus,  for  example,  if  an  employee  was  already 
scheduled  for  a  routine  medical  surveillance  examination  and  it  was 
found  that  the  employee  should  also  be  scheduled  to  follow  up  on  an 
occupational  illness,  the  program  would  attempt  to  schedule  the  follow 
up  on  the  illness  at  approximately  the  same  time  the  always 
scheduled  routine  medical  exam.  This  is  done  in  order  to  reduce  the 
number  of  visits  that  the  employee  must  make  for  medical  examinations 
away  from  his  work.  Similarly,  the  program  "looks  ahead"  for  future 
employee  transport  tasks  involving  the  same  employee  and  attempts  to 
schedule  these  tasks  at  the  same  time.  Thus,  for  example,  if  the 
employee  needed  to  be  scheduled  for  a  follow  up  on  an  occupational 
illness,  the  program  would  look  at  the  requirement  suspense  data  on 
that  employee  ( i . e - ,  the  DS4  data  sets  in  which  the  employee  is  a 
requirement  implementation  unit)  and  determine  if  there  are  any 
employee  transport  tasks  for  that  employee  that  should  take  place  in 
the  near  future  (such  as  a  routine  medical  surveillance  examination 
that  is  upcoming).  If  there  are  any  such  tasks  within  90  days  of  the 
date  that  the  program  is  scheduling  the  current  task  (i.e.,  in  this 
example  within  90  days  of  the  date  on  which  the  follow  up  for  an 
occupational  illness  is  being  scheduled),  the  program  will  attempt  to 
schedule  these  tasks  at  the  same  time  that  the  current  task  is 
scheduled.  This  procedure  reduces  the  number  of  visits  that  the 
employee  must  make  away  from  work  to  participate  in  the  occupational 
health  program.  The  program  thus  uses  the  requirements  suspense  data 
on  date  triggered  requirements  to  enable  the  preparation  of  a 
scheduling  plan  that  considers  both  already  scheduled  tasks  and  tasks 
that  will  need  to  be  scheduled  in  the  near  future  for  the  same 
employee. 

In  the  terms  used  here,  the  tasks  that  were  just  recently  recognized 
as  needing  to  be  scheduled  are  referred  to  a  'currently  being 
scheduled'  tasks.  If,  when  scheduling  the  currently  being  scheduled 
tasks,  it  is  found  that  there  are  tasks  already  scheduled  for  the  same 
employee,  these  tasks  are  referred  to  as  'already  scheduled'  tasks. 

If,  in  checking  the  suspense  data  for  the  same  employee,  it  is  found 
that  there  are  upcoming  tasks  that  should  be  scheduled  at  the  same 
time  as  the  currently  being  scheduled  tasks,  these  tasks  are  referred 
to  as  ‘future  scheduled'  tasks.  Step  F4A-3  only  schedules  those 
groups  of  tasks  containing  at  least  one  already  scheduled  task.  If 
the  program  is  scheduling  employee  transport  tasks  for  an  employee  for 
which  there  are  not  any  already  scheduled  tasks,  this  is  done  in 
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Step  F4A-4  (if  there  is  more  than  one  currently  being  scheduled  or 
future  scheduled  task  for  the  employee)  or  in  Step  F4A-5  (if  there  is 
only  one  task  needing  to  be  scheduled  for  the  employee).  Of  course, 
all  Steps  must  involve  groups  of  tasks  containing  at  least  one 
'currently  being  scheduled*  task. 

Each  group  of  tasks  formed  for  the  purposes  of  scheduling  consists  of 
all  ‘employee  transport1  tasks  for  a  given  employee  and  is  defined  by 
a  list  containing  information  about  the  tasks  in  the  group.  These 
lists  were  called  the  P24  list  in  Step  F4A-2  during  which  the  groups 
(lists)  were  formed.  In  Step  F4A-3,  the  lists  are  referred  to  as  R2 
lists. 

For  each  R2  list  of  tasks.  Step  F4A-3  attempts  to  schedule  all  of  the 
tasks  on  the  list  at  approximately  the  same  time.  The  criteria  for 
' approximately  the  same  time'  is  that  a  task  be  scheduled  to  start  as 
soon  after  one  of  the  already  scheduled  tasks  for  the  same  employee 
has  been  completed  as  possible  and  to  end  no  later  than  the  same  day 
(within  9  hours)  of  one  of  the  already  scheduled  tasks  for  the  same 
employee.  In  order  to  accomplish  this,  the  program  first  reviews  the 
groups  of  tasks  formed  in  Step  F4A-2  to  cull  those  groups  that  clearly 
cannot  be  scheduled  at  approximately  the  same  time,  e.g.,  those  groups 
where  the  sum  of  the  time  slots  required  to  schedule  all  of  the  tasks 
in  the  group  is  greater  than  9  hours.  Then  the  program  forms  groups 
of  calendar  time  slots,  i.e.,  periods  of  time  that  begin  with  an 
already  scheduled  task  and  end  up  to  9  hours  later  or  when  another 
already  scheduled  task  for  the  same  employee  begins.  (These  groups  of 
calendar  time  slots  are  entered  on  a  list  called  the  P177  list  and 
are,  therefore,  referred  to  throughout  Step  F4A-3  as  the  PI 77  list 
entry  groups.)  These  groups  of  calendar  time  slots  may  be  considered 
as  a  first  level  potential  scheduling  map  in  that  they  identify  the 
time  periods  that  are  considered  to  be  at  approximately  the  same  time 
as  the  time  periods  in  which  already  scheduled  tasks  are  scheduled. 

The  next  procedure  is  to  identify  the  series  of  persons  available  to 
perform  each  of  the  tasks  in  the  group  of  tasks  for  an  employee  and 
to  identify  for  which  calendar  time  slot  these  persons  are  available 
for  being  scheduled  to  perform  the  task.  This  adds  a  complication  to 
the  scheduling  of  multiple  tasks  in  which  the  same  employee  will 
participate,  because  not  all  of  the  tasks  in  a  group  (i.e.,  not  all  of 
the  tasks  in  which  a  given  employee  will  participate)  will  necessarily 
be  the  type  of  tasks  that  can  be  performed  by  the  same  person.  This 
is  because  the  scheduling  program  limits  the  scheduling  of  tasks  to 
those  persons  who  are  qualified  to  perform  the  task.  For  example, 

some  of  the  tasks  in  the  same  group  may  be  the  type  for  which  only  a 

physician  is  qualified,  while  others  may  not  require  a  physician.  For 
this  reason,  a  second  level  of  potential  scheduling  maps  is  generated. 
Unlike  the  first  level  of  potential  scheduling  maps,  the  same  set  of 

second  level  potential  scheduling  maps  may  not  apply  to  all  of  the 

tasks  in  the  group  of  tasks  for  the  same  employee.  These  second  level 
potential  scheduling  maps  consist  of  each  of  the  9  hour  calendar  time 
periods  beginning  with  an  already  scheduled  task  (i.e.,  the  first 
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level  scheduling  maps)  for  each  of  the  persons  qualified  to  perform 
the  task,  if  and  only  if  the  qualified  person  has  time  available  for 
scheduling  during  that  calendar  time  slot. 

Having  formed  the  scheduling  maps,  the  program  proceeds  to  schedule 
each  of  the  tasks  in  the  group  onto  one  of  the  maps  for  the  task.  Of 
course,  as  each  task  in  the  group  is  scheduled  for  a  particular  time 
slot,  that  calendar  time  slot  is  eliminated  from  all  maps  (i.e., 
from  all  maps  for  all  of  the  persons  qualified  to  perform  all  of  the 
tasks  in  the  group)  as  being  available  for  scheduling,  because  it  is 
not  acceptable  to  schedule  the  same  employee  to  participate  in  more 
than  one  task  at  the  exact  same  calendar  time.  Multiple  attempts  to 
schedule  all  of  the  tasks  in  a  group  may  be  necessary,  for  this 
reason.  That  is,  because  a  change  in  the  order  in  which  tasks  are 
scheduled  may  enable  the  scheduling  of  tasks  that  could  not  be 
scheduled  in  a  previous  scheduling  attempt,  multiple  attempts  at 
scheduling  the  tasks  beginning  at  different  points  on  the  maps  may 
need  to  be  executed.  Another  reason  why  multiple  attempts  at 
scheduling  may  be  necessary  in  order  to  find  the  optimum  scheduling 
for  all  of  the  tasks  in  a  group  is  that  not  all  of  the  tasks  in  the 
group  will  have  equal  numbers  of  "chances"  for  being  scheduled,  e.g., 
some  will  have  fewer  numbers  of  qualified  persons  available  to  perform 
the  task. 

After  each  attempt  to  schedule  all  of  the  tasks  in  a  group,  i.e., 
after  each  combination  of  task  scheduling  options  has  been  formed,  a 
check  is  made  to  determine  if  this  scheduling  option  meets  the  minimum 
criteria.  The  minimum  criteria  are  defined  as: 

Having  all  of  the  'already  scheduled1  tasks  in  the  group 
scheduled . 

Hav  lg  at  least  one  of  the  'currently  being  scheduled' 
tasks  in  the  group  scheduled. 

Having  all  of  the  calendar  time  slot  groups  (i.e.,  first 
level  maps)  begin  with  the  scheduling  of  one  of  the 
tasks  in  the  task  group.  This  criteria  is  used  in  order 
that  the  employee  who  is  participating  in  the  task  will  be 
scheduled  to  begin  participating  in  the  tasks  at  the  same 
time  as  he/she  was  previously  scheduled  to  begin 
participating  in  the  tasks,  i.e.,  before  the  new 
'currently  being  scheduled'  tasks  were  added  to  the  tasks 
in  which  the  employee  is  to  participate. 

If  the  combination  of  task  scheduling  options  meets  the  minimum 
criteria,  a  check  is  made  to  determine  if  this  combination  of  task 
scheduling  options  is  an  'ideal'  scheduling  option.  The  criteria  for 
an  ideal  schedule  are: 

Having  all  tasks  in  the  group  of  tasks  for  the  same 
employee  scheduled. 
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Having  the  total  calendar  time  for  the  scheduling  of  all 
tasks  scheduled  on  a  given  calendar  time  slot  map  not 
exceed  twice  the  length  of  the  time  required  for 
scheduling  these  tasks.  This  criteria  ensures  that  the 
breaks  in  the  scheduling  of  the  tasks,  including  the 
breaks  between  the  scheduling  of  one  task  and  the 
beginning  of  another  task,  are  not  excessive. 

0  The  combination  of  task  scheduling  options  does  not 
require  rescheduling  of  any  other  tasks. 

0  All  tasks  are  scheduled  in  the  preferred  time  use 
specified  by  the  persons  performing  the  task. 

If  the  combination  of  task  scheduling  options  meets  the  ideal 
scheduling  selection  criteria,  the  tasks  are  scheduled,  according  to 
this  combination  of  task  scheduling  options.  If  not,  further  tries 
are  made  to  attempt  to  schedule  the  tasks.  Further  attempts  to 
schedule  tasks  will  yield  different  combinations  of  task  scheduling 
options  because: 

''  For  each  new  scheduling  attempt  the  program  begins  at  a 

different  point  on  the  calendar  scheduling  maps,  meaning 
that  different  time  slots  are  "used  up"  and,  therefore, 
the  succeeding  tasks  have  different  time  slots  available 
(not  "used  up"  in  the  scheduling  of  previous  tasks). 

u  With  each  successive  try,  the  criteria  for  scheduling 

tasks  becomes  less  rigid.  For  example,  with  the  first 
try,  the  program  excludes  scheduling  options  that  have  any 
interruptions  in  the  scheduling  of  the  task,  require 
rescheduling  of  any  task,  or  are  not  in  the  correct 
preferred  time  use.  With  later  tries,  it  is  acceptable  to 
reschedule  tasks  of  certain  kinds  in  order  to  schedule  all 
of  the  employee  transport  tasks  in  the  group  being 
scheduled  at  approximately  the  same  time.  In  still 
further  scheduling  attempts,  even  more  types  of  tasks  can 
be  rescheduled.  (The  scheduling  of  a  task  in  such  a  way 
that  it  will  result  in  rescheduling  of  other  tasks  is 
allowed  because  it  is  considered  critical  to  schedule  all 
'employee  transport'  tasks  at  approximately  the  same  time 
in  order  to  keep  the  burden  on  the  work  force  of 
participation  in  the  occupational  health  program 
activities  as  low  as  possible.) 

With  each  attempt  to  schedule  tasks,  the  current  combination  of  task 
scheduling  options  is  compared  with  the  "best"  combination  of  task 
scheduling  options  identified  at  that  point.  If  the  current 
combination  of  task  scheduling  options  is  better  than  the  previous 
best  combination  found,  the  current  combination  becomes  the  new  best 
combination  of  task  scheduling  options.  Such  successive  tries  at 
scheduling  continue  until  an  'ideal'  scheduling  is  option  or  until 
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all  scheduling  options  have  been  exhausted,  i.e.,  until  attempts  have 
been  made  to  schedule  each  task  beginning  at  all  points  on  the 
calendar  scheduling  maps.  If  the  program  reaches  a  point  of 
exhausting  all  scheduling  options,  the  program  chooses  the  best 
comoination  of  task  scheduling  options  as  the  preferred  scheduling 
option.  If  this  scheduling  option  requires  rescheduling  a  task,  these 
tasks  are  removed  from  the  current  scheduling  data  and  placed  on  the 
list  of  tasks  that  need  to  be  rescheduled. 

PREVIOUS  STEP:  Step  F4A-3  follows  P76  of  Step  F<+A-2. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 

Data  Retrieval s: 


Rl:  The  list  of  task  identifiers  (ID23)  that  are  the 

labels  for  the  groups  of  employee  transport  tasks 
(i.e.,  the  Step  F4A-2  P24  lists)  that  are  for  the 
same  employee  and  which  include  already  scheduled 
tasks.  This  list  is  from  the  P25  list  generated  in 
Step  F4A-2. 

R2:  The  1’  of  information  about  employee  transport 

tasks  '.ha  have  been  grouped  together  because  they 
are  tasks  for  the  same  employee.  The  lists  include 
informa' ion  about  employee  transport  tasks  that  are 
currently  being  scheduled,  already  scheduled  or 
future  scheduled  tasks  for  the  same  employee.  The  R2 
lists  are  from  the  P24  lists  generated  in  Step  F4A-2. 
Only  the  P24  lists  that  have  a  label,  i.e,  task 
identifier  (ID23)  that  is  on  the  Rl  list  are  needed 
as  inputs  to  the  Step  F4A-3. 

R3:  The  list  of  task  identifiers  (ID23)  that  are  labels 

for  the  "groups"  of  employee  transport  tasks  (i.e., 
the  Step  F4A-2  P24  lists)  that  are  for  the  same 
employee  and  which  include  only  one  task.  The  R3 
list  is  from  the  P68  list  generated  in  Step  F4A-2. 

R4:  The  list  of  task  identifiers  (ID23)  that  are  the 

labels  for  the  groups  of  employee  transport  tasks 
(i.e.,  the  Step  F4A-2  P24  lists)  that  are  for  the 
same  employee  and  which  include  multiple  tasks  on  the 
list,  none  of  which  is  an  ’already  scheduled'  task. 
The  R4  list  is  from  the  P 71  list  generated  in  Step 
F4A-2. 

R5:  Current  date 
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R6:  A  calendar  with  the  number  of  days  in  a  month  for 

each  of  the  months  of  a  year.  This  includes  the 
number  of  days  in  February  for  different  years  (for 
Leap  Years  and  non-Leap  Years).  This  calendar  also 
includes  the  day  of  the  week  (Monday  through  Sunday) 
for  each  day  of  the  year.  This  calendar  is  generated 
once  at  the  initiation  of  OHMIS  and  is  used 
thereafter  with  updates  each  year. 

R7:  Next  available  requirement  implementation  identifier 

( ID9) 

R8:  Next  available  task  identifier  (ID23) 

DS1:  OHMIS  requirement  description  data 

DS4:  Requirement  suspense  data  (i.e.,  date  triggered 

requirements  applicability  data) 

0S5:  Requirements  implementation  data 

DS 23 :  Task  descriptions  data 

DS24:  Specific  task  scheduling  data 

0S25:  Facility  data  by  task  type 

DS26:  Regular  weekly  schedule  availability  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

DS28:  Contact  and  location  data 

0L34:  List  of  qualified  employee  identifiers  ( ID4)  by  task 
type  (C 78)  and  by  OHMIS  service  area  (ID10) 

DL36:  List  of  requirement  implementation  units  (or  sets  of 
units)  linked  to  their  corresponding  task  identifier 
(ID23),  OHMIS  service  area  identifier  ( ID  10 )  and 
whether  the  task  is  an  'employee  transport1  type  of 
task 

DL37:  List  of  the  task  identifier  (ID23)  by  the  name 

facility  identifier  ( I D 8 )  in  which  the  task  will  take 
place  and  by  its  OHMIS  service  identifier  ( 1010) 

DL38:  List  of  task  identifiers  (ID23)  by  requirement 

implementation  identifier  (109)  and  by  OHMIS  service 
rnea  (IUIO) 

UL 39:  !  ist  of  task  identifiers  (ID23)  for  tasks  that  need 

to  be  rescheduled  by  OHMIS  service  area  (  I D 10 ) 
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DL40:  List  of  weekly  schedule  identifiers  (ID28)  by 

employee  identifier  (ID4)  and  by  OHMIS  service  area 
( 1D1G ) 

DL41:  List  of  the  monthly  schedule  identifiers  (ID27)  for 
an  OHMIS  service  area  (ID10)  with  the  corresponding 
year  and  month  covered  by  the  monthly  schedule  data 
^ DS2 7 )  identified  by  the  1027  and  tne  employee 
identifier  (ID4)  of  the  employee  performing  the  tasks 
scheduled  on  this  DS27  data 

PROCESSING  (P  =  Processing  substep:  FN  =  For  Next  (program  logic 
loop) ) : 

FNl :  FOR  each  task  identifier  (ID23)  ori  the  R1  list: 

PI:  Locate  the  R2  list  that  has  the  ID23  for  this  iteration  of 

FNl  as  its  label. 

P2:  Store  a  counter,  called  the  P2  counter.  The  value  in  the 

P2  counter  will  be  the  total  number  of  time  slots  required 
to  complete  all  of  the  unscheduled  tasks  on  the  R2  list 
from  PI  (i.e.,  those  tasks  that  are  not  'already 
scheduled').  Store  the  value  of  'O'  in  the  P2  counter. 
Retain  the  value  in  the  P2  counter  throughout  FNl. 

P3:  Store  a  counter,  called  the  P3  counter.  The  value  in  the 

P3  counter  will  be  the  number  of  time  slots  required  to 
complete  the  currently  being  scheduled  tasks  on  the  R2 
list  from  Pi.  Store  the  value  of  O'  in  the  P3  counter. 
Retain  the  value  in  the  P3  counter  throughout  FNl. 

P4:  Store  a  counter,  called  the  P4  counter.  The  value  in  the 

P4  counter  will  be  the  number  of  time  slots  required  to 
complete  the  already  scheduled  tasks  on  the  R2  list  from 
Pi.  Store  the  value  of  'O'  in  the  P4  counter.  Retain  the 
value  in  the  P4  counter  throughout  FNl. 

P5:  Store  a  counter,  called  the  P5  counter.  The  value  in  the 

PS  counter  will  be  the  number  ^f  Lime  blots  required  to 
complete  the  future  scheduleo  tasks,  if  any,  on  the  R2 
list  from  PI . 

Store  the  value  of  'O'  in  the  P5  counter.  Retain  the 
value  throughout  FNl. 

FNl.l:  FOR  each  entry  (i.e.,  each  of  11  data  elements  about  a 
task)  on  the  R2  list  from  PI: 

Pb:  Identify  the  requirement  application  identifier  (IDS)  in 

data  element  (3)  for  the  entry  on  the  R2  list  from  PI  for 
this  iteration  of  FNl.l. 
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P 7 :  Put  the  ID5  from  P6  on  a  temporary  list  called  the  P7 

list.  This  is  the  list  of  all  tasks  on  the  R2  list  from 
PI.  Retain  the  P7  list  throughout  FNl. 

P8:  NEXT  FN1.1;  end  of  FNl.l,  60  TO  FNl. 2  (P9). 

FNl. 2:  FOR  each  ID5  on  the  P7  list: 

P9:  Locate  the  entry  (i.e.,  set  of  11  data  elements)  on  the  R2 

list  from  Pi  for  this  ID5. 

P10:  Determine  the  value  in  data  element  (2)  (code  for  type  of 

task  being  scheduled)  for  the  R2  list  entry  located  in  P9. 
Store  this  value  throughout  FNl. 2. 

Pll:  Determine  tne  value  in  data  element  (9)  (i.e.,  the  number 

of  time  slots  required  to  complete  this  task)  for  the  R2 
list  entry  located  in  P9. 

P12:  Is  the  value  from  Pll  greater  than  '32'  (i.e.,  greater 

tnan  8  hours)?  Yes  (i.e.,  this  task  takes  more  than  a  day 
co  conduct  and,  therefore,  it  should  not  be  scheduled  next 
to  another  task  (or,  have  other  tasks  scheduled  next  to 
it,  if  this  is  an  'already  scheduled'  task))  =  P13;  No  = 

P 19 

P13:  Is  the  value  stored  in  P10  a  '1',  ‘2‘  or  '3'?  1  =  P17 ;  2 

=  P 14 ;  3  =  P14 

P14:  Remove  the  entire  data  entry  located  in  P9  (all  11  data 

elements)  from  the  R2  list  located  in  PI. 

P15:  Remove  the  ID5  for  this  iteration  of  FNl. 2  from  the  P7 

list. 

P16 :  GO  TO  P32  (next  FNl. 2). 

P17:  Put  the  ID5  for  this  iteration  of  FNl. 2  on  a  t i  'orary 

list  cal  led  the  P17  list. 

P18:  GO  TO  P lb  . 

P19:  Is  the  value  stored  in  P 10  a  '1',  '2'  or  '3'?  1  =  P20;  2 

=  P25;  3  =  P29 

P20:  Identify  the  task  identifier  (ID23)  in  data  element  (1)  on 

the  R2  list  entry  located  in  P9. 

P21 :  Add  the  1D23  from  P20  to  a  temporary  list  called  the  P 21 

list.  Retain  this  list  throughout  FNl. 


P22: 


Add  tne  value  from  Pll  to  the  P3  '>unter. 


at* 
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P23:  Add  the  value  from  Pll  to  the  P2  counter. 

P24 :  GO  TO  P32  (next  FN1.2). 

P2S:  Identify  the  1023  in  data  element  (1)  on  the  R 2  list 

located  in  P9. 

P 26:  Add  the  1023  from  P25  to  a  temporary  list  called  the  P26 

list.  Retain  this  list  throughout  FNl. 

P27:  Add  the  value  from  Pll  to  the  P4  counter. 

P28:  GO  TO  P32  (next  FNl. 2). 

P29:  Add  the  105  for  this  iteration  of  FNl. 2  to  a  temporary 

list  called  the  P29  list.  Retain  this  list  throughout 
FNl. 

P30:  Add  the  value  from  Pll  to  the  P5  counter. 

P31 :  GO  TO  P23. 

P32:  NEXT  FNl. 2;  end  of  FNl. 2,  GO  TO  P33. 

P33:  Are  there  any  ID5s  on  the  P17  list?  Yes  (i.e.,  there  are 

'currently  being  scheduled'  tasks  that  require  longer  than 
8  hours  to  complete  on  the  R2  list  from  PI)  =  FNl. 3  (P34); 
No  =  P48 

FNl. 3  FOR  each  105  on  the  P 1 7  list: 

P34:  Locate  the  entry  (i.e.,  set  of  11  data  elements)  on  the  R2 

list  from  PI  for  this  105. 

P35:  Identify  the  task  identifier  (ID23)  in  data  element  (1)  on 

the  R2  list  entry  located  in  Py' 

P36:  Generate  a  new  R2  list  (i.e.,  a  new  Step  F4A-2  P24  list). 

Put  the  1023  from  P35  as  the  label  on  the  new  R2  list. 

Copy  the  R2  list  entry  from  this  iteration  of  FNl. 3  (as 
located  in  P34)  onto  the  new  R2  list  as  the  first  (and 
only)  entry  (set  of  11  data  elements)  on  the  new  R2  list. 
(Generate  a  new  R2  list  each  time  P36  is  executed,  i.e., 
do  not  erase  previously  generated  R2  lists.  Treat  the  R2 
lists  as  though  they  were  generated  in  P 24  of  Step  F4A-2.) 

P37 :  Remove  the  entire  data  entry  (all  11  data  elements)  for 

the  R2  list  data  entry  located  in  P34  from  the  R2  list 
located  in  PI. 

P38:  Add  the  1023  for  this  iteration  of  FNl. 3  to  the  R3  list 

(i.e.,  the  Step  F4A-2  P68  list  of  labels  of  P24  lists  that 
contain  on ly  one  task  ) . 
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P39:  NEXT  FN1.3;  end  of  FNl. 3,  GO  TO  P40. 

P40:  Are  there  any  ID23s  on  the  P21  list  (i.e.,  were  any  ID3s 

put  on  the  P21  list  during  FN1.2)?  Yes  =  P45;  No  (i.e., 
all  of  the  'currently  being  scheduled'  tasks  on  the  R2 
list  from  PI  required  more  than  8  hours  to  complete  the 
task)  =  P41 

P41:  Erase  the  R2  list  located  in  Pi. 

P42:  Erase  the  ID23  for  this  iteration  of  FNl  from  the  Rl  list 

(i.e.,  from  the  Step  F4A-2  P25  list  of  labels  of  P24  lists 
containing  multiple  tasks  at  least  one  of  which  is  an 
'already  scheduled'  task). 

P43:  Erase  all  lists  counters  generated  in  this  iteration  of 

FNl. 

P44:  60  TO  P1046  (next  FNl). 

P45:  Is  the  ID23  for  this  iteration  of  FNl  on  the  P21  list? 

Yes  =  P48;  No  (i.e.,  the  R2  list  from  PI  is  now  mislabeled 
as  it  is  labeled  with  a  ‘currently  being  scheduled'  task 
that  is  no  longer  included  on  the  R2  list)  =  P46 

P46:  Change  the  task  identifier  (ID23)  that  is  the  label  on 

the  R2  list  from  PI  (i.e.,  for  this  iteration  of  FNl)  to 

be  one  of  the  ID23s  on  the  P21  list. 

P47:  Locate  the  ID23  for  this  iteration  of  FNl  on  the  Rl  list 

(i.e.,  on  the  Step  F4A-2  P25  list)  and  replace  that  ID23 

with  the  1023  used  in  P46  to  relabel  the  R2  list  from  Pi. 

(Note:  It  is  important  that  this  new  label  (1023)  on  the 

Rl  list  be  put  in  the  same  spot  on  the  list  as  the  1023 
for  this  iteration  of  FNl,  not  at  the  end  of  the  Rl  list. 
If  this  is  not  done,  the  FNl.l  and  FNl. 3  iterations  will 
be  repeated,  because  the  program  will  arrive  at  the  ID23 
from  the  relabeled  R2  list  a  second  time.)  Also,  replace 
the  1023  for  this  iteration  of  FNl  with  the  1023  used  in 
P46  to  relabel  the  R2  list  from  PI.  That  is,  change  the 
1023  for  this  iteration  of  FNl  so  that  the  program  will 

consider  this  iteration  of  FNl  to  be  processing  the  group 

of  tasks  with  the  new  label  identified  in  P46.  This  is 
rational,  because  the  R2  list  being  processed  in  this 
iteration  of  FNl  has  not  changed,  only  the  label  for  this 
R2  list  has  changed. 

P48:  Are  there  still  any  ID23s  on  the  P26  (already  scheduled) 

list?  Yes  =  FNl. 4  (P52);  No  (i.e.,  all  of  the  'already 
scheduled'  tasks  on  the  R2  list  from  PI  required  more  than 
8  hours  to  complete;  because  the  R2  list  from  PI  does  not 
contain  any  'already  scheduled'  tasks,  this  R2  list  should 
not  be  processed  in  Step  F4a-3)  =  P49 
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P49:  Is  there  still  more  than  one  ID5  on  the  P7  list?  Yes  = 

P5U;  No  =  P51 

P50:  Identify  the  task  identifier  (ID23)  that  is  the  label  on 

the  R2  list  from  PI,  i.e.,  the  task  identifier  (ID23)  for 
this  iteration  of  FNl.  Put  this  ID23  on  the  R4  list 
(i.e.,  the  Step  F4A-2  P71  list  of  labels  of  P24  (R2)  lists 
containing  groups  of  tasks,  none  of  which  are  'already 
scheduled'  tasks).  GO  TO  P42. 

P51:  Identify  the  task  identifier  (ID23)  that  is  the  label  on 

the  R2  list  from  PI,  i.e.,  the  ID23  for  this  iteration  of 
FNl.  Put  this  1023  on  the  R3  list  (i.e.,  the  Step  F4A-2 
P68  list  of  labels  of  P24  (R2)  lists  containing  only  one 
task).  GO  TO  P42. 

FNl. 4:  FOR  each  ID23  on  the  P21  (‘currently  being  scheduled') 
list: 

P52:  Locate  the  entry  on  the  R2  list  from  PI  with  the  ID23  for 

this  iteration  of  FNl. 4  in  data  element  (1).  Locate  the 
105  in  data  element  (3)  on  this  entry,  also. 

P53:  Does  data  element  (8)  of  the  R2  list  entry  located  in  P52 

have  a  value  (i.e.,  a  facility  identifier  ( ID8) )  in  it? 

Yes  =  P56;  No  =  P54 

Pb4:  Put  the  ID5  from  P52  on  a  temporary  list  called  the  P54 

list. 

P55 :  GO  TO  P70  (next  FNl. 4). 

P56:  Identify  the  ID8  in  data  element  (8)  of  the  R2  list  entry 

from  P52. 

P57:  Is  there  any  P58  record?  Yes  =  P6 0;  No  (i.e.,  this  is  the 

first  task  on  the  P21  list  for  which  the  facility  in  which 
the  task  will  be  conducted  is  known)  =  P58 

P58:  Store  the  108  identified  in  P56  throughout  FNl. 

P59:  GO  TO  P 70  (next  FNl. 4). 

P60:  Is  the  108  from  P56  the  same  as  the  ID8  stored  in  P58? 

Yes  =  P54;  No  =  P61 

P61:  Are  there  any  P62  lists?  Yes  =  FNl. 4.1  ( P65 ) ;  No  =  P62 

Start  a  list,  called  the  P62  list.  (Generate  a  new  P62 
list  each  time  P62  is  executed,  i.e.,  do  not  erase  P62 
lists  generated  in  previous  iterations  of  FNl. 4.)  Label 
this  P62  list  with  the  ID8  from  P56.  Put  the  ID5  from  P52 
on  this  P62  list. 


P62 : 
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P63:  Put  the  108  from  P56  on  a  temporary  list  called  the  P63 

list.  The  P63  list  is  the  list  of  labels  of  P62  lists. 

P64:  GO  TO  P70  (NEXT  FNl.4). 

FN1.4.1:  FOR  each  108  on  the  P63  list: 

P65:  Is  the  108  from  P56  the  same  as  the  108  for  this  iteration 

of  FNl.4.1?  Yes  =  P66;  No  =  P69  (next  FNl.4.1) 

P66:  Locate  the  P62  list  with  the  108  in  this  iteration  of 

FNl.4.1  as  its  label. 

P67:  Add  the  105  from  P52  onto  the  P62  list  located  in  P66. 

P68:  GO  TO  P70  (next  FNl.4). 

P69:  NEXT  FNl.4.1;  end  of  FNl.4.1,  GO  TO  P62. 

P70:  NEXT  FNl.4;  end  of  FNl.4,  GO  TO  FNl.5  (P71). 

FNl.5:  FOR  each  ID3  on  the  P26  (already  scheduled)  list: 

P71:  Locate  the  entry  on  the  R2  list  from  PI  with  the  1023  for 

this  iteration  of  FNl.5  in  data  element  (1).  Locate  the 
ID5  in  data  element  (3)  on  this  entry. 

P72:  Does  data  element  ^3)  of  the  R2  list  entry  located  in  P71 

nave  a  value  ( i . e . ,  an  ID8) ?  Yes  =  P75;  No  =  P73 

P73:  Put  the  105  from  P71  onto  the  P54  list. 

P74:  GO  TO  P88  (next  FNl.5). 

P75:  Identify  the  108  in  data  element  (8)  of  the  R2  list  entry 

from  P71. 

P76:  Is  the  108  from  P75  the  same  as  the  108  stored  in  P58? 

Yes  =  P73;  No  =  P 77 

P77:  Are  there  any  10 8s  on  the  P63  list?  Yes  =  FN 1 .5.1  ( P 78 ) ; 

No  =  P83 

FNl.5.1:  FOR  each  108  on  the  P63  list: 


P78:  Is  the  108  from  P75  the  same  as  the  108  for  this  iteration 

of  FNl.5.1?  Yes  =  P79;  No  =  P82  (next  FNl.5.1) 

P79:  Locate  the  P62  list  with  the  108  for  this  iteration  of 

FNl.5.1  as  its  label . 


P80: 


Add  the  ID5  from  P71  onto  the  P62  list  located  in  P79. 
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P81 :  GO  TO  P88  (next  FN1.5). 

P82:  NEXT  FN1.5.1;  end  of  1.5.1,  GO  TO  P82. 

P83:  Identify  the  value  in  data  element  (9)  (number  of  time 

slots  required  to  complete  the  task)  of  the  R2  list  entry 
from  P71 . 

P84:  Subtract  the  value  identified  in  P83  from  the  P4  counter. 

P85 :  Remove  the  entire  entry  (all  11  data  elements)  located  in 

P71  from  the  R2  list  from  PI. 

P86:  Remove  the  ID23  for  this  iteration  of  FN1.5  from  the  P26 

(already  scheduled)  list. 

P87:  Remove  the  ID5  from  P71  from  the  P7  (all  tasks)  list. 

P88:  NEXT  FN1.5;  end  of  FN1.5,  GO  TO  FNl.6  (P89). 

FN1.6:  FOR  each  ID5  on  the  P29  (future  scheduled)  list: 


P89:  Locate  the  entry  on  the  R2  list  from  PI  with  the  ID  5  for 

this  iteration  of  FNl.6  in  data  element  (3). 

P90:  Does  data  element  (8)  of  the  R2  list  entry  located  in  P89 

have  a  value  (i.e.,  an  ID8) ?  Yes  =  P93;  No  =  P91 

P91 :  Put  the  ID5  for  this  iteration  of  FNl.6  onto  the  P54  list. 

P92:  GO  TO  P106  (next  FNl.6). 

P93:  Identify  the  108  in  data  element  (8)  of  the  R2  list  entry 

from  P89. 

P94:  Is  the  ID8  from  P93  the  same  as  the  ID8  stored  in  P58? 

Yes  =  P91;  P  -  P95 

P95:  Are  then  any  ID8s  on  the  P63  list?  Yes  =  FN 1 .6.1  (P96); 

No  =  P101 

FN1.6.1:  FOR  each  108  on  the  P63  list: 

P96:  Is  the  ID8  from  P93  the  same  as  the  ID8  for  this  iteration 

of  FNl.6.1?  Yes  =  P97 ;  No  =  P100  (next  FNl.6.1) 

P97:  Locate  the  P62  list  with  the  ID8  for  this  iteration  of 

FNl.6.1  as  its  label. 

P98:  Add  the  ID5  for  this  iteration  of  FNl.6  onto  the  P62  list 

located  in  P97. 


P99 :  GO  TO  P106  (next  FNl.6). 
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P100:  NEXT  FNl.6.1;  end  of  FN1.6.1,  GO  TO  P101. 

P101:  Identify  the  value  in  data  element  (9)  (time  slots 

required  to  complete  the  task)  of  the  R2  list  entry  from 
P89. 

P102:  Subtract  the  value  identified  in  P101  from  the  P5  counter. 

P103:  Remove  the  entire  entry  (all  11  data  elements)  located  in 
P89  from  the  R2  list  located  in  PI. 

P104:  Remove  the  105  for  this  iteration  of  FN1.6  from  the  P29 
(future  scheduled)  list. 

P 105 :  Remove  the  ID5  for  this  iteration  of  FN 1.6  from  the  P7 
(all  tasks)  list. 

P106:  NEXT  FNl. 6;  end  of  FNl.6,  GO  TO  P107. 

P107:  Are  there  any  ID8s  on  the  P63  list?  Yes  (i.e.,  some  of 
the  tasks  on  the  R2  list  from  Pi  should  not  be  scheduled 
together  because  they  are  to  be  conducted  in  different 
facilities)  =  FN1.7  (P108);  No  =  P163 

FN1.7:  FOR  each  of  the  ID8s  on  the  P63  list: 

P108:  Locate  the  P62  list  with  the  ID8  for  this  iteration  of 
FNl.l  as  its  label. 

FNl.7.1:  FOR  each  ID5  on  the  P62  list  located  in  P108: 

P109:  Locate  the  entry  on  the  R2  list  from  PI  with  the  ID5  for 
this  iteration  of  FNl.7.1  in  data  element  (3).  Is  the 
code  in  data  element  (2)  of  this  R2  list  entry  a  '1'?  Yes 
=  P 1 10 ;  No  =  P 11 2  (next  FNl.7.1) 

P 110 :  Identify  and  store  the  task  identifier  (ID23)  in  data 

element  (1)  of  the  R2  list  entry  located  in  P109. 

Pill:  GO  TO  P 1 1 3 . 

PI  12 :  NEXT  FNl ,7.1.  (Note:  End  of  FNl.7.1  will  never  be 
reached . ) 

Pi 1 3 :  Start  generating  a  new  R2  list  (i.e.,  a  new  Step  F4A-2  P24 
list).  Put  the  ID23  from  P 110  as  the  label  on  the  new  R2 
list.  Generate  a  new  R2  list  each  time  P 1 1 3  is  executed, 
i.e.,  do  not  erase  the  previous  R2  lists.  Treat  the  R2 
lists  generated  in  PI 1 3  as  though  they  were  generated  in 
P24  of  Step  F4A-2. 

FNl. 7.2:  FOR  each  IDS  on  the  P62  list  located  in  P108: 
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P 11 4 :  Locate  the  entry  on  the  R2  list  from  Pi  with  the  ID5  for 
this  iteration  of  FNl. 7.2  in  data  element  (3). 

P115:  Copy  the  R2  list  entry  located  in  P114  onto  the  new  R2 
list  generated  in  P113,  i.e.,  the  R2  list  generated  in 
this  iteration  of  FNl. 7. 

P116:  Identify  the  value  in  data  element  (9)  (time  slots 

required  to  complete  the  task)  on  the  R2  list  entry  from 
P 114 . 

P 11 7 :  Is  the  code  in  data  element  (2)  of  the  R2  list  entry  from 

P 1 1 4  a  *1',  '2'  or  '3'?  1  -  P128;  2  =  P118;  3  =  P124 

P 11 8:  Identify  the  task  identifier  (ID23)  in  data  element  (1)  of 

the  R2  list  entry  located  in  P 11 4 . 

P 11 9 :  Remove  the  1023  identified  in  P 11 8  from  the  P26  (already 
scheduled)  list. 

P 120 :  Subtract  the  value  identified  in  P 116  from  the  P4  counter. 

P 12 1 :  Remove  the  entire  R2  list  entry  (all  11  data  elements) 
located  in  P 11 4  from  the  R2  list  located  in  PI. 

P122:  Remove  the  105  for  this  iteration  of  FNl. 7. 2  from  the  P7 
list. 

P123:  GO  TO  P132  (next  FNl. 7. 2). 

P124:  Remove  the  ID5  for  this  iteration  of  FNl. 7. 2  from  the  P29 
(future  scheduled)  list. 

P125:  Subtract  the  value  identified  in  P 116  from  the  P5  counter. 

P126:  Subtract  the  value  identified  in  P116  from  the  P2  counter. 

P127:  GO  TO  P121. 

P128:  Identify  the  task  identifier  (1023)  in  data  element  (1)  of 

the  R2  list  entry  located  in  P 1 1 4 . 

P129:  Remove  the  1023  identified  in  P128  from  the  P21  (currently 
being  scheduled)  list. 

PlJU:  Subtract  the  value  identified  in  P 1 1 6  from  the  P3  counter. 

P131 :  GO  TO  P126. 

PI 32:  NEXT  FNl. 7.2;  end  of  FNl. 7.2,  GO  TO  P133. 
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P133:  Store  a  counter  with  the  value  'O'.  This  counter,  called 
the  P 1 33  counter,  will  be  a  count  of  the  number  of  entries 
on  the  newly  generated  R2  list  from  P 1 1 3 . 

FNl.7.3:  FOR  each  entry  on  the  newly  generated  R2  list  from 
P 113 : 

P134:  Add  '1'  to  the  P133  counter. 

P135:  Is  the  code  in  data  element  (2)  of  the  P 1 1 3  R2  list  entry 
for  this  iteration  of  FNl.7.3  a  '2*  (already  scheduled 
task)?  Yes  =  P136;  No  =  P138  (next  FN 1.7.3) 

Pi 36 :  Generate  a  temporary  flag,  called  the  P136  flag, 

indicating  that  the  newly  generated  R2  list  (from  P 11 3 ) 
does  include  already  scheduled  tasks.  (Note:  If  this 
flag  has  already  been  generated  in  previous  iterations  of 
FN 1 .7.3,  proceed  to  P137.) 

P137:  NEXT  FNl.7.3;  end  of  FNl.7.3,  GO  TO  P138. 

P138:  Identify  the  label  (task  identifier  ( ID23 ) )  on  the  newly 
generated  R2  list  from  P 1 1 3 . 

P139:  Is  the  P 133  counter  equal  to  a  1 1 1 ?  Yes  =  P140;  No  =  P144 

P140:  Add  the  1023  from  P138  to  the  R3  list  (i.e.,  the  Step 

F4A-2  P68  list  of  P24  (R2)  list  labels  for  P24  (R2)  lists 
that  only  contained  *  1  *  task  on  them). 

P 141 :  Is  the  1023  from  P 138  the  same  as  the  ID23  for  this 

iteration  of  FN 1  (i.e.,  the  label  for  the  R2  list  from 
PI)?  Yes  =  P 142 ;  No  =  P149  (next  FN1.7) 

P142:  Remove  the  ID23  from  the  R1  list  (i.e.,  from  the  Step 
F4A-2  P25  list  of  labels  of  P24  (R2)  lists  for  P24  (R2) 
lists  containing  multiple  tasks  at  least  one  of  which  is 
an  'already  scheduled'  task). 

P 1 4 3 :  GO  TO  P149  (next  FN1.7). 

P144 :  Is  there  a  P136  flag?  Yes  =  PI47;  No  =  P145 

P 145 :  Add  the  1023  from  P 1 38  to  the  R4  list  (i.e.,  the  Step 

F4A-2  P71  list  of  P24  (R2)  list  labels  for  P24  (R2)  lists 
with  multiple  tasks  none  of  which  is  an  ‘already 
scheduled1  task). 

P 146 :  GO  TO  PI41. 

P 1 4 7 :  Is  the  1023  from  P 1 38  the  same  as  the  1023  for  this 

iteration  of  FNl?  Yes  =  P149  (next  FN1.7);  No  -  P147 


P148: 

P149: 
P150: 
P151 : 
P 15  2 : 

P153: 

P 15  4 : 

P155: 

P 1 5  6 : 

P15  7: 

P 158: 

P159: 

P 160 : 
P 16 1 : 

P 16  2 : 
P 1 6  3 : 
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Add  the  1023  from  P138  to  the  end  of  the  R1  list  (i.e., 
the  Step  F4A-2  P25  list  of  P24  (R2)  list  labels  for  P24 
(R2)  lists  that  contain  multiple  entries  at  least  one  of 
which  is  an  'already  scheduled'  task). 

NEXT  FN1.7;  end  of  FN1.7,  GO  TO  P150. 


Erase  the  P62  lists  generated  in  this  iteration  of  FNl. 

Erase  the  P63  list  generated  in  this  iteration  of  FNl. 

Are  there  still  any  entries  on  the  P21  list?  Yes  =  P153; 
No  =  P41 


Is  the  ID23  for  this  iteration  of  FNl  on  the  P21  list? 

Yes  =  P 156 ;  No  =  P154 

Change  the  task  identifier  (ID23)  that  is  the  label  on  the 
R2  list  from  PI  (i.e.,  for  this  iteration  of  FNl)  to  be 
one  of  the  I D 23s  on  the  P21  list. 

Locate  the  1023  for  this  iteration  of  FNl  on  the  R1  list 
(i.e.,  on  the  Step  F4A-2  P25  list)  and  replace  that  ID23 
with  the  1023  used  in  P153  to  relabel  the  R2  list  from  PI. 
Also  replace  the  ID23  for  this  iteration  of  FNl  with  the 
1023  used  in  P153  to  relabel  the  R2  list  from  PI.  (See 
note  in  P47  for  an  explanation  of  the  rational  for  P155.) 

Are  there  still  any  ID23s  on  the  P26  (already  scheduled) 
list?  Yes  =  P163;  No  =  P157 


Identify  the  task  identifier  (ID23)  that  is  the  label  on 
the  R2  list  from  PI,  i.e.,  the  ID23  for  this  iteration  of 
FNl. 

Is  there  more  than  one  ID5  on  the  P7  list?  Yes  =  P159;  No 
=  P 161 


Put  the  1023  identified  in  P157  on  the  R4  list  (i.e.,  the 
Step  F4A-2  P71  list  of  P24  (R2)  list  labels). 


GO  TO  P42 . 


Put  the  1023  identified  in 
Step  F4A-2  P68  list  of  P24 


P 15 7  on  the  R3  list  (i.e., 
(R2)  list  labels). 


the 


GO  TU  P42 . 


Is  the  value  in  the  P3  counter  (time  slots  required  to 
complete  all  of  the  'currently  being  scheduled'  tasks  on 
the  R2  list  from  PI)  greater  than  '32'?  Yes  (i.e., 
although  no  individual  task  requires  more  than  8  hours. 


the  combination  of  all  of  the  currently  being  scheduled 
tasks  now  on  the  R2  list  from  PI  requires  more  than  8 
hours  and,  therefore,  it  is  not  possible  to  schedule  all 
of  these  tasks  at  one  time)  -  P164;  No  =  P172 

P164:  Are  there  any  ID5s  on  the  P29  (future  scheduled  tasks) 
list?  Yes  =  FN1.8  (P165);  No  =  P175 

FN1.8  FOR  each  requirement  application  identifier  (ID5)  on  the 
P29  list: 

P 165 :  Locate  the  entry  on  the  R 2  list  from  Pi  with  the  ID5  for 
this  iteration  of  FN1.8  in  data  element  (3). 

P 166 :  Erase  the  entire  :2  list  entry  (all  11  data  elements) 
located  in  P165  from  the  R2  list  located  in  PI. 

P 1 6 7 :  NEXT  FN1.8;  end  of  FN1.8,  GO  TO  P168. 

P 168 :  Erase  the  P29  list. 

P 16 9 :  Set  ♦’he  P5  counter  to  'O'. 

P170:  Set  the  P2  (total  required  time  slots  for  unscheduled 
tasks)  counter  to  be  equal  to  the  P3  counter  (required 
time  slots  for  'currently  being  scheduled'). 

P171 :  GO  TO  P175 . 

P172:  Is  the  value  in  the  P5  counter  (time  slots  required  for 
future  scheduled  tasks)  greater  than  '32'?  Yes  =  FN1.8 
(P165) ;  No  =  P173 

P 1 73 :  Calculate  the  sum  of  the  value  in  the  P5  counter  (future 
scheduled  tasks)  and  the  value  int  he  P3  counter 
(currently  being  scheduled  tasks). 

P 1 7 4 :  Is  the  sum  derived  in  P173  greater  than  '32'?  Yes  =  FN1.8 

(P165 ) ;  No  =  P 1 75 

P 1 75 :  Expand  each  entry  on  the  P26  (already  scheduled)  list  of 
I D 2 3 s .  Next  to  each  1023  on  the  P26  list  leave  a  blank 
field  for  a  value  (1-99)  indicating  into  which  group  the 
1023  belongs.  The  ID23s  will  be  grouped  by  groups  of 
'already  scheduled'  lD23s  that  are  scheduled  at 
approximately  the  same  time.  The  value  in  the  field  next 
to  the  1023  will  be  an  arbitrary  number  indicating  to 
which  of  these  groups  the  1023  belongs. 

P 1 7 6 :  Store  the  value  '1'.  This  will  be  the  counter  used  to 
arbitrarily  group  already  scheduled  tasks  that  have  been 
scheduled  at  approximately  the  same  time. 
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P 17 7 :  Start  a  list,  called  the  P177  list.  Each  entry  on  the 

P177  list  will  have  4  data  elements: 

(1)  The  value  in  the  PI 76  counter 

(2)  The  time  slot  information  for  the  time  that  the  first 
already  scheduled  task  in  the  group  of  already 
scheduled  tasks  labeled  with  the  value  in  data 
element  (1)  is  scheduled  to  start 

(3)  The  time  slot  information  for  the  time  slot  that  is 
'36'  (9  hours)  time  slots  later  than  the  start  time 
slot  (i.e.,  the  time  slot  given  in  data  element  (2)), 
or,  the  time  slot  that  is  just  before  the  start  time 
slot  of  the  first  task  in  the  next  group  of  tasks 
identified  by  data  element  (1),  whichever  smaller. 


(4)  The  number  of  time  slots  between  the  time  slot  in 
data  element  (2)  and  the  time  slot  in  data  element 
(3) 

The  P 1 7 7  list  will  be  in  order  of  groups  of  tasks  having 

the  earliest  to  latest  start  times  (data  element  (2)). 

Time  slot  information  for  the  P 1 7 7  list  consists  of  ^ 

parts: 

(1)  monthly  schedule  identifier  (ID27); 

(2)  the  year  shown  on  the  D527  data  for  the  ID27  in  part 

(1); 

(3)  the  month  shown  on  the  DS27  data  for  the  1027  from 
part  (1); 

(4)  a  date  ( 1-31 ) ; 


(5)  a  time  slot  number  (number  from  1  to  96  for  the 
quarter  of  an  hour  period  during  a  day);  and, 

(6)  day  of  the  week  shown  on  the  DS27  data  for  the  date 
in  part  (1)  and  identified  from  R6. 

FN1.9:  FOR  each  1023  on  the  P26  list: 


P 1 7 3 :  Locate  the  entry  on  the  R2  list  from  PI  with  this  1023  in 
data  element  (1). 


P 1 7 9 :  Identify  the  5  parts  of  the  time  slot  information  for  the 
start  time  for  the  task  in  this  iteration  of  FNl.9. 
Parts~T^~4  and  b  of  the  time  slot  information  for  the 
start  time  are  in  data  element  (Ilia)  on  the  R2  list 
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entry  located  in  P178.  Part  2  (year)  and  part  3  (month) 
are  obtained  from  the  DS27  data  corresponding  to  the  ID27 
in  part  1. 

P180:  Is  the  time  slot  identified  in  P179  for  a  time  slot  that 

is  equal  to  or  earlier  than  the  R5  date  (i.e.,  the  current 
date)?  (Note:  To  determine  this,  examine  parts  2  (year), 
3  (month)  and  4  (date)  of  the  time  slot  information  from 
P179.)  Yes  (i.e.,  the  'currently  being  scheduled'  tasks 
and  the  R2  list  from  PI  should  not  be  scheduled  next  to 
the  task  in  this  iteration  of  FN 1.9  because  this  task  is 
before  the  current  date)  =  P 181 ;  No  =  P187 

P 181 :  Locate  the  value  in  data  element  (9)  (time  slots  required 
to  complete  the  task)  in  the  R2  list  entry  from  P178. 

P182:  Subtract  the  value  identified  in  P 181  from  the  P4  counter. 

P183:  Erase  the  ID23  for  this  iteration  of  FNl.9  from  the  P26 
list. 

P 184 :  Locate  the  requirement  application  identifier  (ID5)  in 
data  element  (3)  of  the  R2  list  entry  from  P178. 

P185:  Erase  the  ID5  identified  in  P184  from  the  P7  list. 

P 186 :  Erase  the  entire  R2  list  entry  (all  11  data  elements) 
located  in  P178  from  the  R2  list  located  in  PI. 

P187:  Are  there  still  any  entries  (ID23s)  on  the  P 26  list?  Yes 
=  P188;  No  =  P 15 7 

P188:  Is  there  a  P195  flag?  Yes  =  P197;  No  =  P189 

P139:  Identify  the  5  part  time  slot  information  for  the  end 

time  of  the  task  in  this  iteration  of  FNl.9.  This  is 
from  data  element  (10b)  of  the  R2  list  entry  located  in 
P178. 

FNl.9.1:  FOR  each  1023  on  the  P21  (currently  beinq  scheduled) 
list: 

P 190 :  Locate  the  entry  on  the  R2  list  from  PI  that  has  the  ID23 
for  this  iteration  of  FN 1 .9.1  in  data  element  (1). 

PI 91:  Examine  data  element  (4)  (due  date)  of  the  R2  list  entry 
from  PlyO.  Does  it  contain  a  date  (i.e.,  is  there  a  due 
date  for  this  task)?  Yes  =  P192;  No  (i.e.,  there  is  at 
least  one  task  that  could  be  scheduled  next  to  the  task  in 
this  iteration  of  FNl.9  without  overrunning  a  due  date)  = 

P 19 1 
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P192:  Identify  the  due  date  in  data  element  (4)  of  the  R2  list 
entry  from  P 190 - 

P193:  Is  the  date  on  which  the  already  schedule  task  in  this 
iteration  of  FN 1.9  is  scheduled  to  end  (as  determined  in 
P189)  equal  to  or  later  than  the  due  date  from  P192?  Yes 
(i.e.,  the  task  in  this  iteration  of  FN 1 .9.1  could  not  be 
scheduled  next  to  the  already  scheduled  task  in  this 
iteration  of  1.9  because  it  would  mean  scheduling  the 
FNl. 9.1  task  after  its  due  date;  if  no  unscheduled  tasks 
are  found  next  to  which  the  task  in  this  iteration  of 
FN 1.9  can  be  scheduled,  i.e.,  if  the  end  of  FN 1.9.1  is 
reached  without  an  answer  of  'No'  in  either  P189  or  PI 91 , 
then  the  FNl.9  task  will  be  eliminated  as  a  task  next  to 
which  tasks  can  be  scheduled  in  this  iteration  of  FNl)  = 
P194  (next  FNl. 9.1);  No  (i.e.,  there  is  at  least  one  task 
that  could  be  scheduled  next  to  the  task  in  this  iteration 
of  FNl. 9  without  overrunning  a  due  date)  =  P 197 

P194:  NEXT  FNl. 9.1;  end  of  FNl. 9.1,  GO  TO  P 195 . 

P195:  Generate  a  temporary  flag,  called  the  P195  flag, 
indicating  that  FNl. 9.1  has  been  executed. 

P196 :  G„  TO  P131. 

P197:  Start  a  temporary  list,  called  the  P197  list.  Each  entry 
on  the  P 19 7  list  will  have  three  data  elements: 

(1)  A  task  identifier  (1023); 

(2)  A  start  time  slot  information  set  (6  Dart  time  slot 
information)  for  the  tas*  in  data  element  (1);  and 

(3)  An  end  time  slot  information  set  for  this  task 

The  order  of  the  P 1 9  7  1 i « t  is  important.  The  P197  list  is 
in  order  of  tasks  with  the  earliest  to  latest  start  times 
(data  element  (2)). 

P198:  Generate  the  3  parts  of  an  entry  to  the  P197  list.  Data 

element  (1)  is  the  ID23  for  this  iteration  of  FNl. 9.  Data 
element  (2)  is  the  start  time  slot  information  from 
P179.  Data  element  (3)  is  the  end  time  slot  insinuation 
from  Pld9. 

P 1 9 9 :  Are  there  any  entries  (sets  of  3  data  elements)  on  the 
P 1 9 7  list?  Yes  =  FNl. 9. 2  (P20 c)\  No  =  PJOU 

P2UU:  Enter  the  P 1 9 7  list  entry  generated  ;n  •’ I nt  nr  '•')>)’ 
list  as  the  first  entry  to  tne  list. 
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P2U1:  GO  TO  P209  (next  FN1.9). 

FNl.9.2:  FOR  each  entry  on  the  P197  list: 


P202:  Locate  the  P197  entry  for  this  iteration  of  FN 1-9.2. 

P203:  Identify  the  start  time  slot  in  data  element  (2)  of  the 
P197  list  entry  identified  in  P202. 

P204:  Is  the  start  time  identified  in  P203  later  than  the  start 
time  identified  in  P179?  Yes  =  P205;  No  =  P207  (next 
FN1.9.2) 

P205:  Enter  the  P 1 9 7  list  entry  generated  in  P198  onto  the  P197 
list  in  the  spot  immediately  above  the  P197  list  entry 
for  this  iteration  of  FNl.9.2. 

P206 :  GO  TO  P209  (next  FN1.9). 

P207:  NEXT  FNl.9.2;  end  of  FNl.9.2,  GO  TO  P208. 

P208:  Enter  the  P 197  list  entry  generated  in  P198  onto  the  P197 
list  as  the  last  entry  on  the  list. 

P209:  NEXT  FNI .9;  end  of  FN1.9,  GO  TO  FNl.lO  (P210). 

r N 1 . 1 o ;  FOR  each  entry  on  the  P197  list: 

P2i0:  Locate  this  entry  (set  of  3  data  elements)  on  trie  P 19 7 
list. 

P 21 1 :  Identify  the  task  identifier  (ID23)  that,  is  data  element 

(1)  for  the  P 19 7  list  entry  located  in  P210. 

P212:  Locate  the  start  time  slot  in  data  element  (2)  for  the 
P197  list  entry  from  P 210 . 

P 21 3 :  Locate  the  end  time  slot  in  dat3  element  (3)  for  the 
P197  list  entry  from  P210. 

P?14:  Is  the  P 1 9 7  entry  located  in  P210  tne  first  entry  on  the 

P197  list?  Yes  =  P215;  No  =  F::?l 

P 2 1 5 :  Begin  to  generate  an  entry  to  the  P177  list.  Data  element 
(1)  of  the  Pi 77  list  entry  should  be  the  value  in  P176. 
Data  element  (2)  of  the  PI  77  list  entry  should  be  the 
start  time  in  data  element  (2)  of  the  P 1 9 7  list  entry  in 
this  iteration  of  FNl.lJ,  i.e.,  the  start  time  located  in 
P  212. 

Plio;  determine  f.ne  value  for  data  element  (3)  (end  tone  slot) 

it  the  Pi//  list  entry  started  in  P2ib.  This  is  the  value 


i 
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that  is  '36'  (9  hours)  later  than  the  time  slot  identified 
in  P212,  i.e.,  9  hours  after  the  start  time  slot  in  data 
element  (2)  of  the  P177  list  entry  started  in  P215.  This 
is  referred  to  as  the  P216  time  slot. 

Note:  The  following  are  the  processing  substeps  (PS)  for 
deriving  the  P216  time  slot  information: 

PS1:  Identify  part  (5)  (time  slot  number)  of  the  time 

slot  information  from  P212. 

PS2:  Add  '36'  (9  hours)  to  the  value  from  PS1. 

PS3:  Is  the  value  derived  in  PS2  greater  than  '96'?  Yes 

=  PS6 ;  No  =  PS4 

PS4:  Parts  ( 1 ) - ( 4 )  and  part  (6)  of  the  P216  time  slot 

information  are  the  same  as  the  P212  time  slot 
information.  Part  (5)  is  the  value  in  PS2. 

PS5 :  60  TO  P217. 

Ps6:  Subtract  '96'  from  the  PS2  value.  This  is  part  (5) 

of  the  P2I6  time  slot. 

PS 7 :  Identify  part  (4)  (day)  of  the  time  slot 

information  from  P212. 

PS8:  Add  '1'  to  the  value  in  PS7. 

PS9:  Identify  part  (3)  (month)  and  part  (2)  (year)  of 

the  time  slot  information  from  P212. 

PS10:  Use  R6  to  identify  the  last  day  (28  through  31)  for 
the  month  from  PS9  (and,  if  necessary,  the  year 
from  PS9) . 

PS  11:  Is  the  value  from  PS8  greater  than  the  value  from 
PS10  (last  day  of  the  month)?  Yes  =  PS14;  No  = 

PS12 

PS12:  Parts  (l)-(3)  of  the  P216  time  slot  information  are 
the  same  as  parts  (l)-(3)  of  the  P212  time  slot 
information.  Part  (4)  is  the  value  in  PS8. 

PS13 :  60  TO  PS22. 

PS14:  Part  (4)  (day)  of  the  P216  time  slot  is  '1'. 

PS15:  Part  (1)  (1027)  of  the  P216  time  slot  should  be 
left  blank. 
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PS16:  Add  ‘l1  to  the  value  in  part  (3)  (month)  of  the 

P212  time  slot  information  (as  identified  in  PS9). 

PS17:  Is  the  PS16  value  equal  to  '13'?  Yes  =  PS20;  No  = 
PS18 

PS18:  Part  (3)  (month)  of  the  P216  time  slot  information 
is  the  value  in  PS16.  Part  (2)  (year)  of  the  P 21 6 
time  slot  information  is  the  value  in  part  (2)  of 
the  P212  time  slot  information  (as  determined  in 
PS9). 

PS  1 9 :  GO  TO  PS22 . 

PS20:  Part  (3)  (month)  of  the  P216  time  slot  information 
is  '1'  . 

PS21:  Ado  ' 1 1  to  the  value  in  part  (2)  of  the  P212  time 
slot  information  (as  determined  in  PS9).  This  is 
the  value  for  part  (2)  (year)  of  the  P216  time  slot 
information. 

PS 22 :  Identify  part  (6)  (day  of  the  ween.)  of  the  time 
slot  information  from  P212. 

P S 2 3 :  Is  the  PS 22  value  equal  to  '7'?  Yes  =  PS24;  No  - 
PS26 

Pb24:  Part  (6)  (day  of  the  week)  of  the  P216  tune  si  it 
information  is  ' 1 ' . 

PS25  :  GO  TO  P217. 

PS26:  Add  'I'  to  the  PS 22  value.  This  is  the  value 
part  (6)  of  the  P216  time  slot  information. 

PS27 :  GO  TO  P217. 

P217:  Add  the  P216  time  slot  derived  above  to  data  element  (3; 
oi  the  P 1 7 7  list  entry  started  in  P215. 

P213:  Fill  data  element  (4)  of  the  P177  list  entry  started  in 
P 21 S  with  the  value  '36'. 

P219:  Add  the  value  stored  in  the  P176  counter  to  the  P2b  list 
entry  for  the  ID23  identified  in  P 21 1 . 

P220 :  GO  TO  P232  (next  FNl.10). 

P 22 1 :  Is  the  end  time  slot  identified  in  P213  later  than  the 

end  time  slot  information  in  data  element  (3)  of  the 
last  PI//  entry,  i.e.,  is  this  task  scheduled  to  end  at  a 
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time  that  is  more  than  9  hours  after  the  previous  task  was 
scheduled  to  begin?  Yes  (i.e.,  this  task  will  be  grouped 
with  the  next  group  of  tasks)  =  P222;  No  (i.e.,  this  task 
will  be  grouped  with  the  previous  task  because  it  is 
scheduled  at  approximately  the  same  time)  =  P219 

P222:  Add  '1'  to  the  Pi 76  counter. 

P223:  Is  the  start  time  slot  identified  in  P212  later  than  the 
time  slot  information  in  data  element  (3)  of  the  last  P177 
list  entry,  i.e.,  is  this  task  scheduled  to  start  at  a 

time  that  is  more  than  9  hours  after  the  previous  task  is 

scheduled  to  start?  Yes  =  P215;  No  (i.e.,  in  order  not  to 
overlap  with  the  next  group  of  tasks,  the  length  of  time 
for  the  last  group  of  tasks  must  be  shortened  to  end 
immediately  before  this  group  begins)  =  P224 

P224:  Locate  the  last  P177  list  entry.  (Note:  This  will  be  the 
entry  with  the  value  in  data  element  (1)  that  is  '1'  less 
than  the  current  P176  counter.) 

P225:  Erase  the  values  in  data  elements  (3)  and  (4)  in  the  P177 
list  entry  located  in  P224. 

P226:  Subtract  *1'  time  slot  from  time  slot  information  located 

in  P212.  This  is  referred  to  as  the  P 226  time  slot 

information . 

Note:  The  following  are  the  processing  substeps  (PS)  for 
deriving  the  P226  time  slot  information: 

PS  1 :  Identify  the  value  in  part  (5)  (time  slot  number) 

of  the  time  slot  information  from  P212. 

PS2:  Subtract  '1'  from  the  value  located  in  PS1. 

PS3:  Is  the  value  derived  in  PS2  equal  to  or  greater 

than  '1'?  Yes  =  PS4;  No  =  PS6 

PS4:  Parts  ( 1 ) - ( 4 )  and  part  (6)  of  the  P226  time  slot 

information  are  the  same  as  parts  1-4  of  the  P212 
time  slot  information.  Part  (5)  of  the  P226  time 
slot  information  is  the  value  calculated  in  PS 2 . 

PS5 :  GO  TO  P227. 

PS6:  Part  (5)  of  the  P226  time  slot  information  is  equal 

to  '96'  . 

PS7:  Identify  part  (4)  (date)  of  the  time  slot 

information  from  P212. 
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PS8:  Subtract  ‘ 1 1  from  the  value  located  in  PS7. 

PS9:  Is  the  value  derived  in  PS8  equal  to  or  greater 

than  *1*?  Yes  =  PS10;  No  =  PS12 

PS10:  Parts  ( 1 ) - ( 3 )  of  the  P226  time  slot  information  is 
the  same  as  parts  (l)-(3)  of  the  P212  time  slot 
information.  Part  (4)  of  the  P226  time  slot 
information  is  the  value  calculated  in  PS8. 

PS11 :  GO  TO  PS20. 

PS12:  Part  (1)  (ID27)  of  the  P226  time  slot  information 
should  be  left  blank . 

PS13:  Identify  part  (3)  (month)  of  the  time  slot 
information  in  P212. 

PS14:  Subtract  *  1  *  from  the  value  in  PS13. 

PS  15:  Is  the  value  derived  in  PS14  equal  to  or  greater 
than  the  '1'?  Yes  =  PS16;  No  =  PS19 

PS16:  Part  (2)  (year)  of  the  P 226  time  slot  information 
is  the  same  as  part  (2)  of  the  P212  time  slot 
information.  Part  (3)  (month)  of  the  P226  time 
slot  information  is  the  value  in  PS14. 

PS17:  Use  R6  to  identify  the  value  for  the  last  day  of 
the  month  for  the  month  with  the  value  in  PS14 
(and,  if  necessary,  the  year  with  the  value  in  part 
(2)  of  the  P212  time  slot  information).  This  is 
the  value  for  part  (4)  (day)  of  the  P226  time  slot 
information. 

PS13:  GO  TO  PS20. 

PS19:  Subtract  '1'  from  the  value  in  part  (2)  (year)  in 
the  P212  time  slot  information.  This  is  the  value 
of  part  (2)  of  the  P226  time  slot  information. 

Part  (3)  (month)  of  the  P226  time  slot  information 
is  '12'.  Part  (4)  (day)  is  *31'. 

PS20:  Identify  the  value  in  part  (6)  (day  of  the  week)  of 

the  time  slot  information  from  P212. 

PS21:  Is  the  value  in  PS20  equal  to  '1'?  Yes  =  PS22;  No 
=  PS24 

PS22:  Part  (6)  (day  of  the  week)  of  the  P226  time  slot 
informat  ion  is  ' 7 1 . 
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PS23:  GO  TO  P227. 

PS24:  Subtract  '1*  from  the  PS20  value.  This  is  the 
value  for  part  (6)  of  the  P226  time  slot 
information. 

PS 25:  GO  TO  P227. 

P227:  Place  t* e  P226  time  slot  derived  above  into  data  element 
(3)  of  tne  P177  list  entry  located  in  P224  (i.e.,  the  last 
PI 7 7  list  entry). 

P228:  Locate  the  time  slot  information  in  data  element  (2)  of 
the  P177  list  entry  located  in  P224. 

P229:  Determine  the  difference  (number  of  time  slots)  between 
the  P226  time  slot  and  the  P228  time  slot,  i.e.,  between 
data  element  (2)  and  data  element  (3)  of  the  P 1 7 7  listing 
entry  located  in  P224.  This  is  referred  to  as  the  P229 
value. 

Note:  To  derive  the  P229  value,  which  is  known  to  be  less 
than  '37'  time  slots,  follow  these  processing  substeps 
(PS): 

PS1:  Identify  the  value  in  part  (5)  (time  slot  number) 

of  the  P226  time  slot. 

PS2:  Identify  the  value  in  part  (5)  of  the  P228  time 

slot. 

PS3:  Is  the  PS2  value  smaller  than  the  PS1  value?  Yes  = 

PS5;  No  =  PS 4 

PS4:  Add  ' 96 *  to  the  PS1  values. 

PS5:  Subtract  the  PS2  va^e  from  the  PS1  value. 

PS6:  Add  '1'  to  the  PS5  value  (because,  we  are  counting 

the  inclusive  difference  between  the  two  values). 
This  is  the  P229  value. 

PS7:  GO  TO  P230. 

P230:  Place  the  P229  value  derived  above  in  data  element  (4)  of 
the  P 1 7 7  list  entry  located  in  P224. 

P 23 1 :  GO  TO  P215. 

P232 :  NEXT  FNl.10;  end  of  FNl.10,  GO  TO  P233. 
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P 233 :  Locate  the  last  P177  list  entry.  Identify  the  value  in 
data  element  (1)  (PI76  counter  in  this  entry).  This  is 
the  value  for  the  number  of  groups  of  tasks  in  this 
iteration  of  FNl  as  defined  by  P177  entries.  Store  this 
val ue. 

FNl. 11:  FOR  each  requirement  application  identifier  (IDS)  on 
the  P7  (all  tasks)  list: 

P234:  Generate  a  list,  called  the  P234  list.  This  will  be  a 
list  of  all  P177  list  entry  groups  to  which  a  given  task 
belongs.  (Generate  a  new  such  list  each  time  P234  is 
executed,  i.e.,  one  for  each  task;  do  not  erase  previous 
P234  lists  made  in  this  iteration  of  FNl.)  Each  P234  list 
will  be  labeled  with  a  two-part  label  consisting  of  an  ID5 
and  the  code  (1-3)  indicating  whether  the  task  is  a 
currently  being  scheduled,  already  scheduled  or  future 
scheduled  task.  Each  P234  list  entry  will  consist  of  a 
value  (1-99)  indicating  one  of  the  P177  list  entry  groups 
to  which  the  task  belongs. 

P 235 :  Locate  the  entry  on  the  R2  list  from  PI  with  the  ID5  for 
this  iteration  of  FNl. 11  in  data  element  (3). 

P2J6:  Identify  the  value  in  data  element  (2)  (code)  for  the  R2 
list  entry  located  in  P23 5. 

P237:  Generate  a  label  for  the  P234  list  generated  in  this 

iteration  of  FNl. 11.  This  label  consists  of  the  ID5  for 
this  iteration  of  FNl. 11  and  the  code  located  in  P236. 
Place  this  label  on  the  P234  list. 

P238:  NEXT  FNl. 11;  end  of  FNl. 11,  GO  TO  FNl. 12  (P239). 

F N 1 . 1 2 :  FOR  'X'  iterations  (where  ’X’  is  defined  as  the  value 
in  P233);  i.e.,  foi  each  P177  list  entry: 

P239:  Start  a  list  called  the  P239  list.  This  is  a  list  of  the 
tasks  included  in  ->ach  task  group  where  a  task  group  is 
defined  as  a  P177  list  entry.  Generate  a  new  such  list 
each  time  P239  is  executed,  i.e.,  one  for  each  group. 

Label  the  P239  list  generated  in  this  iteration  of  FNl. 12 
with  the  value  for  ’X1  in  tin's  iteration  of  FNl. 12.  Each 
P239  list  entry  will  have  2  data  elements: 

(1)  An  IDS  identifying  the  task;  and 

(2)  A  code  (1-3)  indicating  whether  the  task  is  a 
currently  being  scheduled,  already  scheduled  or 
future  scheduled  task. 

P24Q;  NEXT  FNl. 12;  end  of  HI.  12,  GO  TO  FNl.  13  (P241). 
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FN1.13:  FOR  each  105  on  the  P7  (all  tasks)  list: 

P241:  Locate  the  entry  on  the  R2  list  from  PI  with  the  105  for 
this  iteration  of  FN 1.13  in  data  element  (3). 

P242:  Identify  the  code  in  data  element  (2)  of  the  R2  list  entry 
located  in  P241.  Is  this  code  a  1,  2,  or  3?  1  =  P251; 

2  =  P243 ;  3  =  P251 

P243:  Locate  the  task  identifier  (ID23)  in  data  element  (1)  of 
the  R2  list  entry  from  P241. 

P244:  Locate  the  P26  list  entry  for  the  1023  from  P243. 

P245:  Identify  the  value  in  data  element  (2)  on  the  P26  list 
entry  (as  expanded  in  P175)  from  P 244 .  This  is  the  P177 
list  entry  group  to  which  this  already  scheduled  task 
belongs.  (Note:  Already  scheduled  tasks  can  only  belong 
to  one  group.) 

P24b:  Locate  the  P239  list  with  the  value  from  P245  as  its 
label . 

P247:  Generate  a  P239  list  entry.  This  entry  consists  of  the 
105  for  this  iteration  of  FN 1 .13  and  the  code  identified 
in  P242.  Enter  this  entry  onto  the  P239  list  located  in 
P246. 

P248:  Locate  the  P234  list  with  the  label  consisting  of  the  P239 
list  entry  generated  in  P247  (i.e.,  an  105  and  a  code  from 
1  to  3). 

P249:  Enter  the  value  from  P245  onto  the  P234  list  located  in 
P248. 

P25U:  GO  TO  P256  (next  FN1.13). 

P251:  Locate  the  P234  list  with  the  ID5  for  this  iteration  of 
FN1.13  and  the  code  from  P242  as  its  label. 

FN 1.13.1:  FOR  'X'  iterations  (where  'X'  is  the  value  in  P233, 
i.e.,  for  each  P239  list  label): 

P252:  Store  the  value  in  'X'  for  this  iteration  of  FN 1.13.1  on 
the  P234  list  located  in  P251. 

P 25 3 :  Locate  the  P239  list  with  the  'X'  in  this  iteration  of 
FnI .  13. 1  as  its  label . 

P254:  Generate  a  P239  list  entry.  The  entry  consists  of  the  ID5 
for  this  iteration  of  FiNl.13  and  the  code  identified  in 
P242.  Enter  this  entry  onto  P239  list  located  in  P253. 
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P255:  NEXT  FNl.13.1;  end  of  FNl.13.1,  GO  TO  P256. 

P256:  NEXT  FN1.13;  end  of  FN1.13,  GO  TO  FNl.14  (P257). 

FN1.14:  FOR  'X'  iterations  (where  ‘X1  is  the  value  in  P233, 
i.e.,  for  each  P239  list  label): 

P257:  Locate  the  P177  list  entry  with  the  value  in  'X'  for  this 
iteration  of  FNl.14  as  its  data  element  (1). 

P 25 8 :  Identify  the  value  in  data  element  (4)  (the  number  of  time 
slots  that  make  up  the  total  length  of  the  group  defined 
by  the  P177  list  entry)  of  the  P 1 7 7  list  entry  located  in 
P257. 

P259:  Locate  the  P 239  list  with  the  value  in  'X1  for  this 
iteration  of  FNl.14  as  its  label. 

P260:  Start  a  counter,  called  the  P260  counter,  with  the  value 
'O'.  This  counter  will  be  the  number  of  time  slots 
required  to  complete  all  tasks  in  the  P177  list  entry 
group  of  tasks  for  this  iteration  of  FNl.14. 

P261:  Start  a  counter,  called  the  P261  counter,  with  the  value 
'0‘.  This  counter  will  be  the  number  of  time  slots 
required  to  complete  all  already  scheduled  tasks  in  the 
P 1 7 7  list  entry  group  of  tasks  for  this  iteration  of 
FNl.14. 

P262:  Start  a  counter,  called  the  P262  counter,  with  the  value 
'O'.  This  counter  will  be  the  number  of  time  slots 
required  to  complete  all  currently  being  scheduled  tasks 
in  the  P 1 7 7  list  entry  group  of  tasks  for  this  iteration 
of  FNl.14. 

P263:  Start  a  counter,  called  the  P263  counter,  with  the  value 
'O'.  This  will  be  the  counter  of  the  number  of  time  slots 
required  to  complete  all  future  scheduled  tasks  in  the 
P177  list  entry  group  of  tasks  for  this  iteration  of 
FNl.14. 

P264:  Start  a  counter,  called  the  P2t>4  counter,  with  the  value 
'O'.  This  counter  will  be  the  count  of  the  number  of 
already  scheduled  tasks  in  the  P 1 7 7  list  entry  group  for 
this  iteration  of  FNl.14. 

P2bb :  Start  a  counter,  called  the  P 265  counter,  with  the  value 

'O'.  This  will  be  the  counter  for  the  number  of  currently 
being  scheduled  tasks  int  he  P177  list  entry  group  for 
this  iteration  of  FNl.14. 
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P266:  Start  a  counter,  called  the  P266  counter,  with  the  value 
'O'.  This  counter  will  be  the  count  of  the  number  of 
future  scheduled  tasks  in  the  P177  list  entry  group  for 
this  iteration  of  FNl.14. 

FNl.14.1:  FOR  each  ID5  on  the  P239  list  from  P259: 

P267:  Locate  the  P239  list  entry  with  the  ID5  for  this  iteration 
of  FNl.14. 1  as  data  element  (1)  on  the  entry. 

P268:  Identify  the  code  in  data  element  (2)  on  the  P239  list 
entry  located  in  P267.  Is  this  code  a  '2'?  Yes  =  P269; 

No  =  P272  (next  FNl.14.1) 

P269:  Add  '1'  to  the  P264  counter. 

P270:  Locate  the  entry  on  the  R 2  list  from  PI  with  the  105  for 
this  iteration  of  FNl.14.1  in  data  element  (3). 

P271:  Identify  the  value  in  data  element  (9)  (number  of  time 

slots  required)  of  the  R2  list  entry  from  P270.  Add  this 
value  to  the  P260  counter  and  to  the  P261  counter. 

P 2 72 :  NEXT  FNl.14.1;  end  of  FNl.14.1,  GO  TO  P273. 

P273:  Locate  the  start  time  slot  information  in  data  element 
(2)  of  the  P177  list  entry  from  P257. 

P274:  Locate  the  end  time  slot  information  in  data  element  (3) 
of  the  P177  list  entry  from  P257. 

P275:  Calculate  the  value  that  is  equal  to  the  value  located  in 
P258  (i.e.,  the  length  of  time  slots  for  the  group  of 
tasks  in  this  iteration  of  FNl.14)  minus  the  value  in  the 
P261  counter  (number  of  time  slots  for  the  already 
scheduled  tasks  in  this  group).  Store  this  value. 

FNl.14. 2:  FOR  each  ID5  on  the  P245  list  entry  from  P259: 


P276 : 

Locate  the  P239  list  entry  with  the  ID5  for  this 
of  FNl.14. 2  as  data  element  (1)  on  the  entry. 

i terat i on 

P  2  7  7 : 

Identify  the  code  in  data  element  (2)  on  the  P239 
entry  located  in  P276.  Is  this  code  a  '2'?  Yes 
(next  FNl.14. 2);  No  =  P278 

list 
=  P307 

P278: 

Locate  the  entry  on  the  R2  list  from  PI  with  the 
this  iteration  of  FNl.14. 2  in  data  element  (3). 

ID5  for 

P2/9:  Identify  the  value  in  data  element  (9)  (number  of  time 

slots  required)  of  the  R?  list  entry  from  P278. 
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P280:  Is  the  value  from  P 279  equal  to  or  greater  than  the  value 
located  in  P258?  Yes  (i.e.,  it  is  not  possible  to 
schedule  the  task  in  this  iteration  of  FN 1 .14.2  in  the 
group  of  already  scheduled  tasks  in  this  iteration  of 
FN1.14  because  this  task  requires  too  large  a  number  of 
time  slots  to  complete  the  task  to  fit  the  task  in  the 
time  available  in  this  group  of  tasks)  =  P281;  No  =  P285 

P281:  Erase  the  entire  P239  list  entry  (2  parts)  identified  by 
the  105  for  this  iteration  of  FN 1.14.2  from  the  P239  list 
located  in  P259. 

P282:  Locate  the  P234  list  with  the  ID5  for  this  iteration  of 
FN 1.14.2  as  the  first  part  of  its  label. 

P283:  Erase  the  value  for  'X'  for  this  iteration  of  FN 1.14 

(i.e.,  the  P177  list  entry  (group)  label)  for  the  P234 
list  located  in  PR29. 

P284:  GO  TO  P307  (next  FNl.14.2). 

P285:  Calculate  the  value  that  is  equal  to  the  value  from  P275 
(i.e.,  the  time  slots  in  the  P 1 7 7  list  entry  group  for 
this  iteration  of  FNl.14  that  are  left  after  the  already 
scheduled  tasks  for  this  group  have  been  subtracted)  minus 
the  value  from  P279  (the  time  slots  required  for  the  task 
in  this  iteration  of  FNl.14. 2).  Is  this  value  equal  to  or 
less  than  '1'  (i.e.,  a  ‘O'  or  a  negative  number)?  Yes 
(i.e.,  it  is  not  possible  to  schedule  the  task  in  this 
iteration  of  FNl.14. 2  in  the  group  of  already  scheduled 
tasks  for  this  iteration  of  FNl.14  because  after  the 
already  scheduled  tasks  have  been  scheduled,  there  is  not 
sufficient  numbers  of  time  slots  to  schedule  this  task)  = 
P281 ;  No  =  P286 

P286:  Examine  the  value  in  data  element  (4a)  (due  date)  of  the 
R2  list  entry  from  P278.  Is  there  a  due  date?  Yes  = 

P287 ;  No  =  P289 

P287:  Identify  the  due  date  in  data  element  (4a)  of  the  R2  list 

entry  from  P278. 

P288:  Is  the  due  date  from  P287  equal  to  or  later  than  the  end 

time  slot  information  for  the  P177  list  entry  group  for 
this  iteration  of  FNl.14  (as  determined  in  P 2 74 ) ?  Yes 
(i.e.,  it  is  not  possible  to  schedule  the  task  in  this 
iteration  of  FNl.14.2  in  the  group  of  already  scheduled 
tasks  in  this  iteration  of  FNl.14,  because  it  would  mean 
scheduling  the  task  after  its  due  date)  =  P281;  No  =  P239 

P289:  Examine  the  data  element  (4b)  on  the  R2  list  entry  from 
P278.  Are  there  any  restrictions  for  this  tisk?  Yes  = 

P 290 ;  No  -  P3U1 
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P 2^0 :  Are  ihe  restrictions  for  this  task  standard  restr ictions, 
special  restrictions  or  both?  (The  answer  is  also  from 
data  element  (4b)  on  the  R2  list  entry  from  P278.) 

Standard  restrictions  =  P291;  Special  restrictions  =  P296; 
Both  =  P291 

P291:  Locate  the  0S26  data  corresponding  to  the  ID23  that  is  in 
data  element  (4b)  on  the  ">?  list  entry  from  P278. 

P292:  Identify  the  restricted  day*  on  the  DS26  data  from  P291, 
i.e.,  the  days  of  the  week  for  which  the  entire  day  is 
restricted  so  that  tasks  cannot  be  scheduled  on  this  day. 

P293:  Is  the  day  of  th.  week  that  is  part  (6)  of  the  start 

time  slot  information  from  P 27 3  one  of  the  restricted  days 
identified  in  P292?  Yes  =  P281 ;  No  =  P294 

P294:  Is  the  day  of  the  week  that  is  part  (6)  of  the  end  time 
slot  information  from  P274  one  of  the  restricted  days 
identified  in  P292?  Yes  =  P281 ;  No  =  P295 

P295:  Was  the  answer  in  P290  'both'?  Yes  =  P295  (Note:  This 
task  must  be  a  'currently  being  scheduled'  task  for  this 
answer  to  be  the  answer  as  'future  scheduled'  tasks  cannot 
have  special  restrictions) ;  No  =  P 30 1 

P 29 6 :  Identify  the  ID23  that  is  in  data  element  (1)  of  the  R2 
list  entry  located  in  P278. 

P297:  Locate  the  DS24  data  corresponding  to  the  ID23  from  P296. 

P  98:  Locate  the  special  restricted  days  given  on  the  DS24  data 
from  P297. 

P299:  Is  the  date  in  the  start  tune  slot  information  from  P273 

one  ot  the  restricted  days  identified  in  P398?  Yes  = 

P 281 ;  No  =  P3U0 

P300:  Is  the  date  in  the  end  time  slot  information  from  P274 
one  of  the  restricted  days  identified  in  P3u6?  Yes  = 

P 281 ;  No  =  P3U1 

P3U1:  Is  the  code  identified  in  P 27 7  a  '1'  or  '3'?  (Note:  The 
code  cannot  be  a  '2'  for  P 301  to  have  been  reached.)  1  = 

P  302 ;  3  =  P30b 

P 3U 2 :  Add  '1'  to  the  P2bb  counter. 

P3d3:  Add  the  value  identified  in  P279  to  the  P2b2  counter  and 
to  the  P2b0  counter. 


_ 


STEP  F4A-3 


P304:  GO  TU  P307  (next  FNl.14.2). 

P305:  Add  '1'  to  the  P266  counter. 

P306:  Add  the  value  identified  in  P279  to  the  P263  counter  and 
to  the  P260  counter. 

P307;  NEXT  FNl.14.2;  end  of  FNl.14.2,  GO  TO  P308. 

P308:  Is  the  value  in  the  P265  counter  greater  than  'O'?  Yes 

(i.e.,  there  are  some  currently  being  scheduled  tasks  that 
can  be  scheduled  next  to  the  group  of  already  scheduled 
tasks  for  the  group  in  this  iteration  of  FN 1.14)  -  P324; 

No  (i.e.,  the  group  of  already  scheduled  tasks  for  this 
iteration  of  FN 1 . 14  is  not  an  option  for  scheduling 
'currently  being  scheduled'  tasks)  =  FNl.14.3  (P309) 

FNl.14.3:  FOR  each  105  on  the  P249  list  located  in  P259  (or  the 
P239  list  located  in  P347,  if  there  is  a  P345  flag  of 
'2' ) : 

P309:  Locate  the  P233  list  with  the  ID5  in  this  iteration  of 
FNl.14.3  as  the  first  part  of  its  label. 

P310:  Erase  the  value  from  'X'  for  this  iteration  of  FN 1 .14 

(i.e.,  ‘'he  value  for  the  label  of  a  P 1 7 7  list  entry  group) 
from  '  P233  list  located  in  P309. 

P 31 1 :  Is  the  code  that  is  the  second  part  of  the  P233  list 
located  in  P309  a  '2'  (already  scheduled  task)?  Yes 
(i.e.,  because  this  is  an  already  scheduled  task,  the  P177 
list  entry  group  just  erased  from  the  P233  list  for  this 
task  is  the  only  group  to  which  this  task  can  belong; 
therefore,  because  this  group  has  been  eliminated  as  an 
option  for  scheduling  tasks,  the  already  scheduled  tasks 
in  this  group  are  also  eliminated  as  far  as  possibilities 
for  providing  tasks  next  to  which  the  tasks  in  the  R2  list 
entry  for  this  iteration  of  FN 1  can  be  scheduled)  =  P312; 
No  =  P320  (next  FNl.14.3) 

P312:  Erase  the  P230  list  entry  located  in  P309. 

P313:  Locate  the  entry  on  the  R2  list  from  PI  for  the  task  witn 
the  IDS  for  this  iteration  of  FN 1.14  in  data  element  (3). 

P 31 4 :  Identify  the  1D23  in  data  element  (1)  of  the  R2  list  entry 
from  P 3 1 3 . 

P 31 b :  Erase  the  1023  identified  in  P314  from  the  P26  list? 
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P 31 6 :  Identify  the  value  in  data  element  (9)  (time  slots 

required  for  the  task)  of  the  R 2  list  entry  located  in 
P313 . 

P 31 7 :  Subtract  tne  value  identified  in  P316  from  the  P4  counter. 

P318:  Erase  the  R2  list  en*.ry  (all  11  data  elements)  located  in 
P313  from  the  R2  list  located  in  PI. 

P319:  Erase  the  105  for  this  iteration  of  FN 1.14.3  from  the  P7 
list. 

P320:  NEXT  FNl.14.3;  end  of  FNl.14.3,  GO  TO  P321. 

P321:  Erase  the  P239  list  located  in  P259  (or  the  P 239  list 
located  in  P347,  if  there  is  a  P346  flag  of  '2'). 

P322:  Erase  the  entire  P177  list  entry  (all  4  data  elements)  for 
this  iteration  of  F N 1 .14  from  the  P177  list  for  this 
iteration  of  FNl. 

P323  GO  TO  P325  (next  FNl. 14). 

P 32 4 :  Expand  the  P 1 7 7  list  entry  for  this  iteration  of  FNl. 14  to 
have  eight  more  data  elements.  These  are  data  elements 
(5)  through  (12).  Fill  data  elements  (5)  through  (.11) 
with  the  values  in  the  P260  tnrough  P267  counters.  Fill 
data  element  (12)  with  the  sum  of  the  values  in  the  P26C, 
P266,  and  P267  counters. 

P 3 25 :  NEXT  FNl . 14;  end  of  FNl. 14,  GO  TO  P326. 

P 32 6 :  Are  there  any  entries  still  on  the  P26  list?  Yes  =  FNl. 15 
(P327);  No  (i.e.,  there  are  no  options  (groups  of  already 
scheduled  tasks)  left  for  scheduling  the  tasks  in  this 
iteration  of  FnI  next  to)  =  P  9 

F N 1 . 1 5 :  FOR  eacn  105  on  the  P7  lirt: 

P 32 7 :  Locate  the  P 234  list  with  the  105  for  this  iteration  of 
FNl.  15  as  the  first  part  of  its  label. 

P 32 3 :  Are  there  any  P 1 7 7  list  labels  on  the  P234  list  located  in 
P327  (i.e.,  are  there  are  entries  on  this  P234  list)?  Yes 
=  P 341  (next  FN1.15:;  No  (i.e.,  there  are  no  options 
(groups  of  already  scheduled  tasks)  into  which  the  task  in 
this  iteration  of  FNl.  15  can  be  scheduled)  =  P 32 9 

P329:  Erase  the  135  tor  this  iterati  -o  of  FNl. 15  from  tne  P7 
list. 
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330:  Erase  the  P240  list  located  in  P327. 

P331:  Locate  the  entry  on  the  R2  list  from  Pi  that  has  the  ID5 
for  this  iteration  of  FNl.15  in  data  element  (3). 

P332:  Identify  the  value  in  data  element  (9)  (time  slots 

required  to  complete  the  task)  of  the  R2  list  entry 
located  in  P331. 

P333:  Identify  the  value  in  data  element  (2)  (code  1-3)  of  the 

R2  list  entry  located  in  P331.  Is  this  value  a  '1'  or  a 

'3'?  (Note:  The  code  cannot  be  a  '2'  for  P326  to  have 
been  answered  'No'.)  1  =  P334;  3  *  P338 

P334:  Subtract  the  value  identified  in  P332  from  the  P2  and  P3 
counters. 

P335:  Identify  the  ID23  in  data  element  (1)  of  the  R2  list  entry 
located  in  P331. 

P336:  Erase  the  1023  identified  in  P335  from  the  P21  (currently 
being  scheduled  tasks)  list. 

P337:  Are  there  still  any  1023s  on  the  P21  list?  Yes  =  P340;  No 
=  P41 

P338:  Subtract  the  value  identified  in  P332  from  the  P2  and  P5 
counters. 

P339:  Erase  the  105  for  this  iteration  of  FNl.15  from  the  P29 
(future  scheduled  tasks)  list. 

P340:  Erase  the  entire  R2  list  entry  (all  11  data  elements)  for 
this  iteration  of  FNl  from  the  R2  list  located  in  Pi. 

P341 :  NEXT  FNl.15;  end  of  FNl.15,  GO  TO  P342. 

P342:  Is  the  1023  for  this  iteration  of  FNl  still  on  the  P21 
list?  Yes  =  P343;  No  =  P45 

P343:  Is  there  a  P352  flag?  Yes  =  P344;  No  =  P345 

P344:  Is  the  value  in  the  P345  flag  a  '2'?  Yes  =  P401  (next 
FNl. 16);  No  =  P345 

P345:  Generate  a  flag  called  the  P345  flag.  Store  the  value  ’1' 
in  the  P346  flag.  This  indicates  that  FNl.15  has  been 
executed  once. 

FNl. 16:  FOR  'X'  iterations  (where  'X'  is  the  value  in  P233, 

i.e.,  the  number  of  entries  on  the  original  P177  list): 
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P346:  Is  there  a  P177  list  entry  with  the  value  of  'X'  for  this 
iteration  of  FNl.16  as  its  data  element  (1)?  Yes  =  P347; 
No  =  P401  (next  FNl.16) 

P347:  Locate  the  entry  on  the  P177  list  with  the  value  of  'X' 
for  this  iteration  of  FNl.16  as  its  data  element  (1). 

P348:  Identify  the  value  in  data  element  (4)  (number  of  time 

slots  in  a  P177  list  entry  group)  of  the  P177  list  entry 
located  in  P347.  Store  this  value  throughout  FNl.16. 

P349:  Begin  generating  a  list,  called  the  P349  list.  A  P349 

list  defines  the  time  slots  contained  in  a  particular  P177 
list  entry  group.  Generate  a  new  such  P349  list  each  time 
P349  is  executed;  do  not  erase  previous  P349  lists 
generated  during  this  FNl,  i.e.,  retain  the  P349  lists 
throughout  FNl.  Put  the  value  for  'X*  in  this  iteration 
of  FNl.16  as  the  label  of  the  P349  list. 

There  is  an  entry  on  the  P349  list  for  each  time  slot  in 
the  length  of  time  contained  in  the  P177  list  entry  group 
for  this  iteration  of  FNl.16  as  defined  in  P348.  Each 
such  entry  on  the  P349  list  consists  of  7  data  elements: 

(1)  A  number  from  '1‘  to  'X'  (where  'X'  is  the  value  from 
P348) . 

Time  slot  information;  in  this  case,  this  will  consist  of 
five  parts  (data  elements  (2)  through  (6)): 

(2)  Year; 

(3)  Month; 

(4)  Day  of  the  month  (1-31); 

(5)  Time  slot  number  (1-96);  and, 

(6)  Day  of  the  week 

(7)  A  flag  indicating  whether  this  time  slot  has  been 
tentatively  scheduled.  (Note:  This  data  element 
will  not  be  completed  until  much  later  in  the  Step 
F4A-3  program.  If  there  is  a  flag  of  'S',  it  means 
the  time  slot  is  tentatively  scheduled;  if  there  is  a 
flag  of  'I',  it  means  that  this  time  slot  is  an 
interruption  in  a  task  that  has  been  tentatively 
scheduled;  such  interruptions  are  treated  as 
tentatively  scheduled  time  slots  in  order  to  avoid 
scheduling  other  tasks  in  these  time  slots.  If  there 
is  no  flag,  then  the  time  slot  has  not  been 
tentatively  scheduled.) 
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P350:  Identify  the  6  part  start  time  slot  information  in  data 
element  (2)  of  the  P177  list  entry  located  in  P347. 

P351:  Identify  the  6  part  end  time  slot  information  in  data 

element  (3)  of  the  P177  list  entry  located  in  P347. 

P352:  Start  a  counter,  called  the  P352  counter.  Fill  in  the 

counter  with  the  value  in  part  2  (year)  of  the  start  time 
slot  information  obtained  in  P350. 

P353:  Start  a  counter,  called  the  P353  counter.  Fill  the 

counter  with  the  value  in  part  3  (month)  of  the  start  time 
slot  information  obtained  in  P350. 

P354:  Start  a  counter,  called  the  P354  counter.  Fill  the 

counter  with  the  value  in  part  4  (day  of  the  month)  of  the 
start  time  slot  information  obtained  in  P350. 

P355:  Start  a  counter,  called  the  P355  counter.  Fill  the 

counter  with  the  value  in  part  5  (time  slot  number)  of  the 
start  time  slot  information  obtained  in  P350. 

P356:  Start  a  counter,  called  the  P356  counter.  Fill  the 

counter  with  the  value  in  part  6  (day  of  the  week)  of  the 
start  time  slot  information  obtained  in  P350. 

FN1.16.1:  FOR  'X'  iterations  (where  'X'  is  the  value  from 
P  348 ) : 

P357:  Generate  an  entry  on  the  P349  list  being  generated  for 
this  iteration  of  FNl.16.  Put  the  value  of  'X'  for  this 
iteration  of  FN1.16.1  as  data  element  (1)  on  this  entry. 
Data  elements  (2)  through  (6)  for  this  P349  list  entry 
should  be  the  values  in  counters  P 352  through  P356, 
respectively. 

P358:  Add  '1*  time  slot  to  the  P352  through  P356  counters.  To 
do  this,  follow  these  Process  Substeps  (PS): 


PS1: 

Is  the  value  in  the  P355  (time 
to  '96'?  Yes  =  PS4;  No  =  PS2 

slot 

number) 

equal 

PS2: 

Add  *  1  *  to  the  P355  counter. 

PS3: 

GO  TO  P359  (next  FNl.16.1). 

PS4: 

Is  the  value  in  the  P356  (day  of  the 
equal  to  '7'?  Yes  =  PS7;  No  =  PS5 

week ) 

counter 

PS5: 

Add  '1'  to  the  P356  counter. 

PS6: 

GO  TO  PS8. 
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PS  7 : 

Set  the  P356  counter  as  a  '1'. 

PS8: 

Use  the  R6  list  to  determine  the  number  of  days  in 
a  month  for  the  month  in  the  P353  counter  (and,  if 
necessary,  the  year  in  the  P352  counter). 

PS9: 

Is  the  value  in  the  P354  (day  of 
counter  equal  to  the  last  day  of 
determined  in  PS8) ?  Yes  =  PS12; 

the  month) 
the  month  (as 

No  =  PS10 

PS10: 

Add  '1'  to  the  P354  counter. 

PS11 : 

GO  TO  P359  (next  FNl.16. 1). 

PS12: 

Set  the  P354  counter  to  a  '1'. 

PS13: 

Is  the  value  in  the  P353  (month) 
a  '12'?  Yes  =  PS16;  No  =  PS14 

counter  equal  to 

PS14: 

Add  '1‘  to  the  P353  counter. 

PS15: 

GO  TO  P359  (next  FNl. 16.1). 

PS16: 

Set  the  value  in  the  P353  counter 

to  a  '1'. 

PS17: 

Add  '1'  to  the  value  in  the  P352 

(year)  counter. 

PS18: 

GO  TO  P359  (next  FNl. 16.1). 

P359:  NEXT  FN1.16.1;  end  of  FNl. 16.1,  GO  TO  P360. 

P360:  Locate  the  P239  list  with  the  value  of  ’X’  for  this 
iteration  of  FNl.16  as  its  label. 

FNl.16.2:  FOR  each  entry  on  the  P239  list  from  P360  (i.e.,  each 
task  in  the  P177  list  entry  group  for  this  iteration  of 
FNl.16): 

P361:  Begin  generating  a  list  called  the  P361  list.  This  list 
is  a  copy  of  the  P349  list,  but  it  is  for  a  single  task 
that  is  covered  by  this  iteration  of  FNl.16. 2  rather  than 
for  the  entire  set  of  tasks  in  FNl.16.  Generate  a 
separate  P361  list  each  time  P361  is  executed;  store  these 
lists  throughout  FNl. 

Each  P361  list  has  a  2  part  label.  Part  (1)  consists  of 
the  value  of  ’X'  for  this  iteration  of  FNl.16.  Part  (2) 
is  a  requirement  application  identifier  (105). 
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(1)  The  code  (1-3)  indicating  whether  this  is  a  currently 
being  scheduled,  already  scheduled  or  future 
scheduled  task. 

(2)  The  total  number  of  restricted  time  slots  on  the  P361 
list  for  this  task. 

(3)  The  total  number  of  time  slots  required  to  complete 
this  task. 

(4)  The  total  time  slots  (entries)  on  this  P361  list. 

(5)  Whether  it  is  possible  to  schedule  this  task  using 
this  scheduling  option. 

Each  P361  list  consists  of  the  same  number  of  entries  as 
the  P349  list.  Each  entry  on  the  P361  list  consists  of  7 
data  elements.  The  first  6  data  elements  are  the  same  as 
the  data  elements  in  the  corresponding  entry  on  the  P349 
list,  i.e.,  a  sequential  number  for  the  time  slot,  the 
year,  the  month,  the  day  of  the  month,  the  time  slot 
number  (1-96),  and  the  day  of  the  week.  Data  element  (7) 
consists  of  a  Yes/No  answer  to  whether  the  time  slot 
represented  by  this  entry  on  the  P368  list  is  a  restricted 
time  slot  for  this  task. 

P362:  Locate  the  P239  list  entry  corresponding  to  this  iteration 
of  FN1.16.2. 

P363:  Identify  the  ID5  in  data  element  (1)  on  the  P239  list 
entry  located  in  P362. 

P3 64:  Identify  the  code  (1-3)  in  data  element  (2)  of  the  P239 

list  entry  located  in  P362. 

P365:  Locate  the  entry  on  the  R2  list  from  PI  that  consists  the 
ID5  located  in  P363  in  data  element  (3). 

P366:  Identify  the  value  in  data  element  (9)  (time  slots 
required  to  complete  the  task)  on  the  R2  list  entry 
located  in  P365. 

P367:  Begin  to  fill  in  the  P361  list  newly  generated  in  this 

iteration  of  FNl.16.2.  Part  (1)  of  the  label  is  the  value 
for  'X'  for  this  iteration  of  FN 1.16.  Part  (2)  of  the 
label  is  the  105  from  P363. 

Part  (1)  of  the  data  elements  at  the  top  of  the  P361  list 
(i.e.,  before  the  entries  begin)  is  the  code  from  P364. 
Part  (2)  of  the  data  elements  at  the  top  of  the  P361  list 
is  left  blank  at  this  point.  Part  (3)  of  the  data 
elements  at  the  top  of  the  P361  list  is  the  value  from 


P366.  Part  (4)  of  the  data  elements  at  the  top  of  the 
P361  l’st  is  the  value  from  P348.  Fill  in  the  first  6 
data  elements  of  all  of  the  entries  on  the  P361  list  by 
copying  the  corresponding  6  data  elements  from  the  P349 
list. 

P368:  Examine  data  element  (4b)  on  the  R2  list  entry  from  P365. 
Are  there  any  restrictions  for  the  task  in  this  iteration 
of  FNl.16.2?  Yes  =  P371 ;  No  =  P369 

P369:  Fill  in  part  (2)  of  the  data  elements  at  the  top  of  the 
P361  list  with  an  'O'  (i.e.,  there  are  no  restricted  time 
slots  on  this  P361  list). 

P370:  GO  TO  P398  (next  FNl.16.2). 

P371:  Are  the  restrictions  for  this  task  standard  restrictions? 
(Note:  This  answer  is  also  in  data  element  (4)  on  the  R2 
list  entry  from  P365.)  Yes  =  P372;  No  =  P369 

P372:  Locate  the  DS26  data  corresponding  to  the  weekly  schedule 
identifier  (ID28)  that  is  in  data  element  (4b)  on  the  R2 
list  entry  from  P365. 

FN1.16.2.1:  FOR  each  entry  on  the  newly  generated  P361  list: 

P373:  Identify  the  values  in  data  element  (6)  (day  of  the  week) 
and  data  element  (5)  (time  slot  number)  on  the  P361  list 
entry  for  this  iteration  of  FNl.16.2.1. 

P374:  On  the  DS26  data  from  P372  locate  the  time  slot 

corresponding  to  the  day  of  the  week  (1-7)  and  the  time 
slot  number  (1-96)  identified  in  P373. 

P375:  Does  the  r:  data  from  P372  show  that  the  time  slot 

identified  in  P374  is  available  for  scheduling,  i.e.,  has 
a  'Yes'  (not  restricted)  for  this  time  slot?  Yes  =  P376; 
No  =  P378 

P376:  Mark  data  element  (7)  of  the  P361  entry  for  this  iteration 
of  FNl.16.2.1  with  the  code  'Yes'  (i.e.,  not  restricted). 

P377:  GO  TO  P380  (next  FNl.16.2.1). 

P378:  Mark  data  element  (7)  of  the  P361  list  entry  for  this 
iteration  of  FNl.16.2.1  with  the  code  for  'No'  (i.e., 
restricted) . 

P379:  Add  '1*  to  the  value  stored  in  part  (2)  of  the  data 
elements  at  the  top  of  the  newly  generated  P361  list. 
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P381:  Is  the  code  located  in  P364  a  '2'?  Yes  =  P400  (next 
FNl.16.2);  No  =  P382 

P382:  Derive  the  sum  of  the  values  in  part  (2)  (restricted  time 
slots)  and  part  (3)  (time  slots  required  for  the  task)  of 
the  data  elements  at  the  top  of  the  newly  generated  P361 
list. 

P383:  Is  the  sum  derived  in  P382  equal  to  or  greater  than  the 
value  in  part  (4)  (time  slots  on  the  P361  list)  of  the 
data  elements  at  the  top  of  the  newly  generated  P361  list? 
Yes  (i.e.,  it  is  not  possible  to  schedule  the  task  in  this 
iteration  of  FNl.16.2  in  the  group  of  tasks  in  this 
iteration  of  FN1.16  because,  when  restricted  time  slots 
are  considered,  there  are  not  sufficient  numbers  of  time 
slots  in  this  group  to  schedule  the  task)  =  P387;  No  = 

P384 

P384:  Identify  the  value  in  data  element  (6)  (time  slots 

required  to  complete  the  already  scheduled  tasks  for  this 
P177  list  entry  group)  of  the  P177  list  entry  located  in 
P347. 

P385:  Derive  the  sum  of  the  value  derived  in  P382  and  the  value 
identified  in  P384. 

P386:  Is  the  sum  derived  in  P385  greater  than  the  value  in  part 
(4)  (time  slots,  i.e.,  entries  on  the  P361  list)  of  the 
data  elements  at  the  top  of  the  newly  generated  P361  list? 
Yes  =  P387 ;  No  =  P398  (next  FNl.16.2) 

P387:  Erase  the  entire  P239  list  entry  (2  data  elements)  for 
this  iteration  of  FNl.16.2  from  the  P239  list  located  in 
P360. 

P388:  Locate  the  P234  list  with  the  ID5  from  P363  as  the  first 
part  of  its  label . 

P389:  Erase  the  entry  on  the  P234  list  located  in  P388  that  is 
equal  to  the  value  for  'X'  for  this  iteration  of  FN1.16. 

P390:  Locate  data  element  (5)  on  the  P177  list  entry  located  in 
P347. 

P391:  Subtract  the  value  identified  in  P366  from  the  value  in 
data  element  (5)  located  in  P390.  This  remainder  is  the 
new  value  for  data  element  (5)  of  the  Pi 77  list  entry 
located  in  P347. 
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P392:  Is  the  code  identified  in  P364  a  '1*  or  '3'?  (Note:  It 
cannot  be  a  '21,  because  of  the  answer  in  P277.)  1  = 

P393;  3  =  P396 

P393:  Subtract  *1'  from  the  value  in  data  element  (10)  (number 
of  currently  being  scheduled  tasks)  and  data  element  (12) 
(total  number  of  tasks)  of  the  P177  list  entry  located  in 
P347. 

P394:  Subtract  the  value  identified  in  P366  from  the  value  in 

data  element  (7)  (currently  being  scheduled  time  slots)  of 
the  P177  list  entry  located  in  P347. 

P395:  GO  TO  P398  (next  FNl.16.2). 

P396:  Subtract  '1*  from  the  value  in  data  element  (11)  (number 
of  future  scheduled  tasks)  and  data  element  (12)  (total 
number  of  tasks)  of  the  P177  list  entry  located  in  P347. 

P397:  Subtract  the  value  identified  in  P366  from  the  value  in 

data  element  (8)  (future  scheduled  time  slots)  of  the  P177 
list  entry  located  in  P347. 

P398:  NEXT  FNl.16.2;  end  of  FNl.16.2,  GO  TO  P399. 

P399:  Add  '1*  to  the  P345  flag. 

P400:  Is  the  value  in  data  element  (10)  (number  of  currently 

being  scheduled  tasks)  of  the  P177  list  entry  from  P347  a 
'O'?  Yes  =  FN 1.14.3  (P309);  No  «  P401  (next  FN1.16) 

P401 :  (From  P344  and  P400)  NEXT  FN1.16;  end  of  FN1.16.  GO  TO 
FN1.17  (P403) . 

P402:  Start  a  list  called  the  P402  list.  This  is  a  list  of  the 
employee  identifier  (104)  group  numbers  indicating  to 
which  group  of  users  capable  of  performing  certain  types 
of  tasks  (CT8s)  a  task  belongs. 

FN1.17:  FOR  each  entry  on  the  R2  list  from  PI: 

P403:  Identify  the  value  (1-99)  in  data  element  (11)  (i.e.,  the 
employee  identifier  (104)  group  number  indicating  to  which 
group  of  users  capable  of  performing  this  task,  the  task 
in  this  iteration  of  FNl.17  belongs)  on  the  R2  list  entry 
for  this  iteration  of  FNl.17. 

P404:  Is  the  value  identified  in  P403  on  the  P402  list?  Yes  * 
P409  (next  FNl.17);  No  =  P405. 
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P405:  Place  the  value  from  P403  onto  the  P402  list. 

P406:  Identify  data  element  (6)  (task  type  code  (CT8) )  on  the  R2 
list  entry  for  this  iteration  of  FN1.17.  Also  identify 
data  element  (5)  (OHMIS  service  area  identifier  (ID10)). 

P407:  Using  the  DL34  list,  identify  all  of  the  employee 

identifiers  ( ID4)  for  the  same  CT8  and  ID1Q  as  those 
identified  in  P 406. 

P408:  Generate  a  list,  called  the  P4Q8  list.  (Generate  a  new 
P408  list  each  time  P4Q8  is  executed;  i.e.,  do  not  erase 
previous  P408  lists;  retain  the  P408  lists  throughout  this 
iteration  of  FN1.)  Put  the  value  identified  in  P4Q3  as 
the  label  on  the  P408  list  generated  in  this  iteration  of 
FNl.17.  Add  the  I04s  identified  in  P407  as  the  entries  on 
the  P408  list. 

P409:  NEXT  FNl.17;  end  of  FNl.17,  GO  TO  FN1.18  (P410). 


P410:  Identify  the  first  ID23  on  the  P26  list. 

P411:  Locate  the  0S24  data  corresponding  to  the  1023  from  P410. 

P412:  Identify  the  OHMIS  service  area  identifier  (ID10)  on  the 
0S24  data  from  P411.  Store  this  1010  throughout  FNl. 

FNl.18:  FOR  'X1  iterations  (where  'X'  is  the  value  in  P233, 

i.e.,  the  number  of  entries  on  the  original  P177  list): 

P413:  Is  there  a  P177  list  entry  with  the  value  of  'X1  for  this 
iteration  of  FNl. 16  as  its  data  element  (1)?  Yes  =  P414; 
No  =  P475  (next  FNl.18) 

P414:  Start  a  list,  called  the  P414  list.  This  is  a  list  of  the 
employee  identifier  (ID4)  group  numbers  indicating  to 
which  group  of  user  is  capable  of  performing  certain  types 
of  tasks  (CT8)  a  task  belongs,  for  a  given  PI 77  list 
entry  group.  That  is,  it  is  the  same  type  of  list  as  the 
P402  list,  but  it  is  for  a  given  P177  list  entry  group. 
Place  the  value  of  1 X 1  for  this  iteration  of  FNl.18  as  the 
label  on  the  new  P414  list.  Retain  the  P414  list 
throughout  this  iteration  of  FNl,  i.e.,  do  not  erase 
previously  generated  P414  lists  for  this  iteration  of  FNl. 

P415:  Start  a  list,  called  the  P415  list.  This  is  the  list  of 
employee  identifiers  (I04s)  that  are  capable  of  performing 
any  one  task  in  the  P177  list  group  of  tasks  for  this 
iteration  of  FNl.18  and  associated  scheduling  information 
for  each  of  these  I04s.  Retain  the  P415  list  throughout 
this  iteration  of  FNl;  i.e.,  do  not  erase  other  P415  lists 
generated  in  this  iteration  of  FNl. 
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Each  P415  list  will  have  a  series  of  entries.  Each  P415 
list  entry  will  consist  of  5  data  elements: 

(1)  An  employee  identifier  (104)  that  is  one  of  the 
users  qualified  to  perform  one  or  more  of  the  tasks 
in  the  P177  list  entry  group  covered  by  this  P415 
list 

(2)  A  monthly  schedule  identifier  (ID27).  This 
identifies  the  particular  monthly  schedule  data 
(DS27)  that  contains  the  time  slots  covered  in  the 
P177  list  entry  group  covered  by  the  P415  list  for 
the  ID4  in  data  element  (1) 

(3)  A  second  ID27.  If  the  time  slots  covered  in  the 
P177  list  entry  group  for  this  P415  list  include 
more  than  one  month  (i.e.,  if  the  maximum  of  9 
hours  covered  on  any  P177  list  entry  group  goes 
onto  more  than  one  day  and  the  two  days  include  the 
last  and  first  days  of  two  months),  then  there  will 
need  to  be  two  1027s  to  cover  the  two  months  in  the 
time  slots  for  the  P177  list  entry  group.  This 
data  element  will  be  the  same  as  the  1027  in  data 
element  (2),  if  there  is  only  one  month  covered  by 
the  P177  list  entry  group. 

(4)  Whether  data  element  (2)  and  data  element  (3)  of 
this  P415  list  entry  (i.e.,  the  ID27s)  identify  the 
same  set  of  DS27  data  for  which  one  of  the  already 
scheduled  tasks  around  which  the  P177  list  entry 
group  for  this  iteration  of  FNl.18  were  formed 

(5)  The  number  of  time  slots  not  available  for 
scheduling  on  the  two  0527  monthly  schedules  in 
data  element  (2)  and  data  element  (3)  from  among 
the  time  slots  included  in  the  PI 77  list  entry 
group  for  this  iteration  of  FNl.18 

Place  the  value  of  'X*  for  this  iteration  of  FNl.18  as  the 
label  for  this  P415  list.  The  rest  of  the  data  elements 
on  the  P415  list  are  left  blank  at  this  time. 

P 41 6 :  Start  a  list  of  pairs  of  monthly  schedule  identifiers 

(1027)  that  are  for  the  monthly  scheduled  data  (DS27)  of 
the  already  scheduled  tasks  for  the  P 1 7 7  list  entry  group 
in  this  iteration  of  FNl.18.  (Note:  Pairs  of  ID27s  are 
needed  because  OS27  data  only  covers  one  month  and  a  given 
already  scheduled  task  may  take  more  than  one  day  and  the 
second  day  may  go  onto  a  second  month,  thus  resulting  in 
two  1027s  to  describe  the  time  slots  for  which  the  task  is 
scheduled.  There  cannot  be  more  than  2,  however,  because 
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already  scheduled  tasks  taking  longer  than  32  time  slots 
(8  hours)  have  been  removed  from  the  R2  list  from  PI.) 

FNl.18.1:  FOR  each  entry  on  the  P26  (already  scheduled  tasks) 
lists: 

P417:  Identify  the  value  in  data  element  (2)  (the  P177  list 
entry  group  number)  of  the  P26  list  entry  for  this 
iteration  of  1.18.1.  (Note:  The  P26  list  entry  was 
expanded  in  P175.) 

P418:  Is  the  value  identified  in  P417  the  same  as  the  value  from 
'X'  in  this  iteration  of  FN 1 .18?  Yes  =  P419;  No  =  P425 
(next  FN 1.18.1) 

P419:  Identify  the  task  identifier  (1023)  in  data  element  (1)  of 
the  P26  list  entry  for  this  iteration  of  FNl.18.1 

P420:  Locate  the  entry  on  the  R2  list  from  Pi  with  the  ID23  from 
P419  in  data  element  (1). 

P421:  Identify  part  (1)  (i.e.,  an  ID27)  of  the  start  time  slot 
information  that  is  in  data  element  (10a)  of  the  R2  list 
entry  located  in  P420. 

P422:  Identify  part  (1)  (i.e.,  an  1027)  of  the  end  time  slot 
information  that  is  in  data  element  (10b)  of  the  R2  list 
entry  located  in  P420. 

P423:  Is  the  pair  of  ID27s  identified  in  P421  and  P422  already 
on  P416  list?  Yes  =  P425  (next  FNl.18.1);  No  =  P424 

P424:  Add  the  pair  of  1027s  from  P421  and  P422  to  the  P416  list. 

P425:  NEXT  FNl.18.1;  end  of  FNl.18.1,  GO  TO  P426. 

P426:  Locate  the  P239  list  with  the  value  of  'X'  for  this 
iteration  of  FN 1.18  as  its  label. 

FNl.18.2:  FOR  each  task  (as  identified  by  a  requirement 

application  identifier  (105))  on  the  P239  list  located  in 
P426: 

P427:  Locate  the  entry  on  the  R2  list  from  PI  with  the  105  for 
this  iteration  of  FNl.l 8.2  as  its  label. 

P428:  Identify  the  value  in  data  element  (11)  (task  performer 
group  number)  of  the  R2  list  entry  identified  in  P427. 

P429:  Is  the  value  identified  in  P428  on  the  P414  list  for  this 
iteration  of  FN 1 . 18?  Yes  =  P435  (next  FNl.18.2);  No  = 

P430 
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P430:  Place  the  value  identified  in  P428  onto  the  P414  list  for 
this  iteration  of  FN1.18. 

P431:  Locate  the  P408  list  with  the  value  from  P428  as  its 
label . 

FNl.18.2.1:  FOR  each  ID4  on  the  P408  list  located  in  P431: 

P432:  Is  the  104  for  this  iteration  of  FNl.18.2.1  on  the  P415 

list,  i.e.,  in  data  element  (1)  of  a  P415  list  entry?  Yes 
=  P 434 (  next  FNl.18.2.1);  No  =  P433 

P433:  Place  the  104  for  this  iteration  of  FNl.18.2.1  as  data 
element  (1)  of  a  new  entry  on  the  P415  list. 

P434:  NEXT  FNl.18.2.1;  end  of  FNl.18.2.1,  GO  TO  P435. 

P435 :  NEXT  FN1.18.2;  end  of  FNl.18.2,  GO  TO  P436. 

P436:  Locate  the  P177  list  entry  with  the  value  of  ’X1  in  this 
iteration  of  FN 1  - 18  as  its  data  element  (1). 

P437:  Identify  the  start  time  slot  information  that  in  data 
element  (2)  of  the  P177  list  entry  located  in  P436. 

P438:  Identify  the  end  time  slot  information  that  is  in  data 
element  (3)  of  the  P177  list  entry  from  P436. 

P439:  Identify  the  value  in  data  element  (4)  (number  of  time 

slots  in  the  P 17 7  list  entry  group)  of  the  P177  list  entry 
located  in  P436.  Store  this  value  throughout  FN 1.18. 

FN1.18.3:  FOR  each  entry  on  the  P415  list  generated  in  this 
iteration  of  FN 1.18: 

P440:  Identify  the  employee  identifier  (ID4)  in  data  element  (1) 
on  the  P415  list  entry  for  this  iteration  of  FN1.18.3. 

P441:  Determine  if  there  is  a  DL41  list  entry  (monthly  schedule 
identifiers  (1027)  that  corresponds  to  the  OHMIS  service 
area  identifier  ( ID 10 )  from  P412,  the  ID4  from  P440  and 
the  year  (part  (2))  and  the  month  (part  (3))  of  the  start 
time  information  from  P437.  Yes  =  P446;  No  =  P442 

P442:  Examine  the  DL40  list  and  determine  if  there  are  any 

entries  (i.e.,  weekly  schedule  identifiers  (ID28))  for  the 
1010  from  P 41 2  and  the  ID4  from  P440  and  for  which  the 
DS26  data  corresponding  to  the  1028  covers  the  year  and 
month  and  day  that  are  parts  (2),  (3)  and  (4)  of  the  start 
time  information  from  P437.  Yes  =  P444;  No  (i.e.,  the  104 
from  P440  cannot  be  used  as  a  person  for  whom  the  tasks  in 
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the  P177  list  entry  group  for  this  iteration  of  FN1.18 
belongs  can  be  scheduled,  because  there  is  no  schedule 
availability  data  (DS26)  for  this  user  for  the  time  period 
covered  by  the  P177  list  entry  group)  =  P443 

P443:  Erase  the  entire  P415  list  entry  (all  5  data  elements, 

only  one  of  which  will  have  been  filled  at  this  time)  for 
this  iteration  of  FNl.18.3  from  the  P415  list  generated  in 
this  iteration  of  FN1.18.  60  TO  P474  (next  FNl.18.3). 

P444:  Generate  a  flag  indicating  that  it  was  necessary  to  go  to 
the  Function  F4C  subroutine  from  P444  of  Step  F4A-3  and 
that  the  program  should  return  to  P446  of  Step  F4A-3,  when 
Function  F4C  is  completed.  Retain  this  flag  throughout 
the  time  that  the  user  is  logged  onto  the  system  or  until 
this  flag  has  been  erased  at  completion  of  F4C. 

P445:  Retain  all  temporary  flags,  lists  and  records  generated 

and  in  existence  at  the  time  that  P441  is  executed  (or  at 
the  time  that  P446  is  executed,  if  there  is  a  flag  in 
P448).  Retain  the  1010  from  P 41 2 ,  the  ID4  from  P440  and 
the  year  (part  (2))  and  the  month  (part  (3))  of  the 
start  time  slot  information  from  P437  (or  the  end  time 
slot  information  from  P438,  if  there  is  a  P448  flag). 

These  data  elements  will  be  used  in  Function  F4C.  GO  TO 
FI  of  Step  F4C. 

P446:  Determine  if  there  is  a  0L41  list  entry  that  corresponds 
to  the  1010  from  P412,  the  1D4  from  P440  and  the  year  and 
month  of  the  end  time  slot  information  from  P438.  Yes  = 
P449;  No  =  P447 

P447:  Examine  the  DS40  list  and  determine  if  there  are  any 

entries  (ID28s)  for  the  ID10  from  P412  and  the  1010  from 
P440  and  for  which  the  DS26  data  covers  the  year  and  month 
and  day  that  are  parts  (2),  (3)  and  (4)  of  the  end  time 
slot  information  from  P438.  Yes  =  P448;  No  =  P443 

P448:  Generate  a  flag  as  in  P444  except  that  the  flag  should 

indicate  that  the  program  exited  from  P447  (not  P442)  and 
should  return  to  P449  (not  P446).  GO  TO  P445. 

P449:  Using  the  DL 41  list,  identify  the  ID27  that  corresponds  to 
the  OHMIS  service  area  (ID10)  from  P412,  the  104  from 
P440,  and  the  year  (part  (2))  and  the  month  (part  (3))  of 
the  start  time  information  from  P437. 

P450:  Using  the  DL41  list,  identify  the  ID27  that  corresponds  to 
the  OHMIS  service  area  ( ID 10 )  from  P412,  the  104  from 
P440,  and  the  year  (part  (2))  and  the  month  (part  (3))  of 
the  end  time  slot  information  from  P438. 
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P451:  Enter  the  1027s  from  P449  and  P450  onto  data  elements  (2) 
and  (3)  respectively  of  the  P415  list  entry  for  this 
iteration  of  FNl.18.3. 

P452:  Is  the  pair  of  ID27 s  from  P449  and  P450  on  the  P416  list? 
Yes  =  P453;  No  =  P454 

P453:  Fill  in  data  element  (4)  on  the  P415  list  entry  for  this 
iteration  of  FNl.18.3  with  a  code  meaning  'Yes'.  GO  TO 
P456. 

P454:  Fill  in  data  element  (4)  on  the  P415  list  entry  for  this 
iteration  of  FNl.18.3  with  a  code  meaning  'No'. 

P455:  Start  a  list,  called  the  P455  list.  Generate  a  new  such 
list  each  time  P455  is  executed;  i.e.,  do  not  erase  P455 
lists  until  this  iteration  of  FNl  is  completed.  The  P455 
list  consists  of  the  scheduling  availability  information 
for  a  set  of  DS27  data  (or  a  pair  of  DS27  data  sets)  that 
corresponds  to  a  particular  employee  identifier  (104)  and 
a  particular  P177  list  entry  group. 

The  label  of  each  P455  list  consists  of  5  parts.  These 
five  parts  are  the  same  as  the  five  data  elements  to  a 
P415  list  entry,  i.e.,  (1)  a  P177  list  entry  group  number; 

(2)  the  first  monthly  schedule  identifier  (ID27);  (3)  the 
second  1027;  (4)  whether  the  ID27s  in  (2)  and  (3)  make  up 
a  scheduling  option  containing  an  already  scheduled  task 
for  this  iteration  of  FNl. 18;  and  (5)  the  number  of  time 
slots  not  available  for  this  set  of  DS27  data  from  among 
the  time  slots  for  this  set  of  P177  list  entry  group  time 
slots.  Fill  in  the  P455  list  label  for  the  P455  list 
generated  in  this  iteration  of  FNl.18.3  with  the  values  on 
the  P415  list  entry  for  this  iteration  of  FNl.18.3. 

Each  entry  on  the  P455  list  consists  of  five  data 
elements: 

(1)  A  sequentially  assigned  number  indicating  the  count 
of  P455  list  entries.  This  is  a  number  starting 
with  (1)  and  ending  with  (X)  (where  'X1 2 3 4 5  is  the 
value  from  P439,  i.e.,  the  number  of  P177  list 
group  entries) 

(2)  A  monthly  schedule  identifier  (ID27) 

(3)  A  day  of  the  month  (1-31) 

(4)  A  time  slot  number  (1-96) 

(5)  Whether  this  time  slot  is  available  for  scheduling. 
The  presence  of  a  code  indicates  that  this  time 


STEP  F4A-3 


slot  is  not  available  for  scheduling;  a  blank  in 
this  data  element  indicates  that  it  is  available 
for  scheduling.  Two  codes  CB'  or  1 T* )  may  be  put 
in  this  field.  A  ' B '  indicates  that  the  time  slot 
is  not  available  for  scheduling  because  of  a 
'break'  (user's  time  is  not  available);  a  ' T ' 
indicates  that  the  slot  is  not  available  because 
another  task  is  scheduled  here. 

P456:  Start  a  counter,  called  the  P456  counter.  Fill  the 

counter  with  the  value  in  part  (4)  (day  of  the  month)  of 
the  start  time  slot  information  identified  in  P437. 

P457:  Start  a  counter,  called  the  P457  counter.  Fill  this 

counter  with  the  value  in  part  (5)  (time  slot  number)  of 
the  start  time  slot  information  identified  in  P437. 

P458:  Generate  a  flag,  called  the  P458  flag.  Store  the  value  of 
' 1 '  in  the  P458  flag,  thereby  indicating  that  FN 1 . 18 .3.1 
should  use  the  first  DS27  data  ( i . e - ,  the  DS27  data 
corresponding  to  the  ID27  from  P449,  not  P450). 

FNl.18.3.1:  FOR  'X'  iterations  (where  'X'  is  the  value  from 
P439,  i.e.,  the  number  of  time  slots  in  the  P177  list 
entry  group  for  this  iteration  of  FNl.18): 

P459:  Is  the  P458  flag  a  ' 1 '  or  a  '2'?  1  =  P460;  2  =  P462 

P460:  Locate  the  DS27  data  corresponding  to  the  ID27  identified 
in  P449.  Start  adding  an  entry  to  the  newly  generated 
P455  list.  Data  element  (1)  is  the  value  for  'X'  in  this 
iteration  of  FNl.18, 3.1.  Data  element  (2)  is  the  ID27 
from  P449.  Data  elements  (3)  and  (4)  are  the  values  in 
the  D456  and  P475  counters  respectively. 

P461 :  GO  TO  P463. 

P462:  Locate  the  DS27  data  corresponding  to  the  ID27  identified 
in  P450.  Start  adding  an  entry  to  the  P455  list;  follow 
the  instructions  in  P460,  except  data  element  (2)  is  the 
ID27  from  P450,  not  P449. 

P463:  Locate  the  time  slot  on  the  DS27  data  for  this  iteration 
of  FNl.18. 3.1  (i.e.,  the  DS27  data  from  P460  or  P462)  that 
is  for  the  day  of  the  month  with  the  val je  in  the  P456 
counter  and  the  time  slot  number  with  the  value  in  the 
P 45 7  counter. 

P464:  Is  the  time  slot  from  P463  available  for  scheduling? 

(Note:  This  information  and  that  for  answering  the  P465 
through  P470  questions  is  given  on  the  DS27  data  for  this 
iteration  of  FNl.18. 3.1  as  identified  in  P460  or  P462.) 
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Yes  =  P465;  No  (i.e.,  this  time  slot  is  not  available  for 
scheduling)  =  P471 

P465:  Is  the  time  slot  from  P463  currently  already  scheduled? 

Yes  3  P466;  No  (i.e.,  this  time  slot  is  available  for 
scheduling)  =  P472 

P466:  Is  the  task  in  the  P463  time  slot  one  for  which  the  user 
specified  the  schedule?  Yes  (i.e.,  this  task  cannot  be 
rescheduled)  =  P 471 ;  No  =  P467 

P467:  Is  the  task  scheduled  in  the  P463  time  slot,  one  of  those 
on  the  P26  (already  scheduled  tasks)  list  for  this 
iteration  of  FNl?  (Note:  To  determine  this,  compare  the 
task  identifier  (ID23)  on  the  DS27  data  with  the  ID23s  on 
the  P26  list.)  Yes  (i.e.,  this  task  can  be  rescheduled)  = 
P472;  No  3  P468 

P468:  Is  the  task  scheduled  in  the  P464  time  slot  for  an 

'employee  transport*  type  of  task?  Yes  (i.e.,  this  task 
cannot  be  rescheduled)  =  P471;  No  3  P469 

P469:  Is  the  task  in  the  P463  time  slot  one  for  which  there  are 
special  restrictions?  Yes  (i.e.,  this  task  cannot  be 
rescheduled)  =  P471;  No  3  P470 

P470:  Is  the  task  in  the  P463  time  slot  one  for  which  a 

Scheduling  Notice  (015)  is  supposed  to  be  generated?  Yes 
(i.e.,  this  task  cannot  be  rescheduled)  3  P471;  No  3  P472 

P471:  Add  '1'  to  the  value  in  data  element  (5)  of  the  P415  list 
entry  for  this  iteration  of  FNl. 18. 3.  Also  enter  a  code 
in  data  element  (5)  of  the  P455  list  entry  generated  in 
P460  (or  P462).  This  code  should  be  a  '8'  if  P464  was 
answered  'No';  otherwise,  the  code  is  a  1 T ' . 

P472:  Add  '1'  time  slot  to  the  P456  and  the  P457  counters,  and, 
if  applicable,  change  the  flag  in  P458.  To  do  this, 
follow  these  Processing  Substeps  (PS): 

PS1:  Is  the  value  in  the  P457  counter  (time  slot  number) 

equal  to  a  '96'?  Yes  =  PS4;  No  3  PS2 

PS2:  Add  '1*  to  the  P457  counter. 

PS3:  GO  TO  P473  (next  FNl. 18. 3.1). 

PS4:  Set  the  P457  counter  to  '1'. 


PS5:  Identify  the  value  in  part  (2)  (year)  and  part  (3) 

(month)  of  the  P437  time  slot  information. 
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PS  6: 

Use  the  R6  list  to  determine  the  number  of  days  in 
a  month  for  the  month  (and,  if  necessary,  year) 
with  the  value  identified  in  PS5. 

PS  7: 

Is  the  value  in  the  P456  counter  (day  of  the  month) 
equal  to  the  last  day  of  the  month  (as  determined 
in  PS6 ) ?  Yes  =  PS8;  No  =  PS10 

PS8: 

Set  the  P456  counter 

to  ’1'. 

PS9: 

GO  TO  PS11. 

PS10: 

Add  *1'  to  the  value 

in  the  P456 

counter. 

PS11 : 

Is  the  P458  flag  a  '1 
(next  FNl.18.3.1) 

'  or  '2'?  1 

=  PS12;  2  =  P473 

PS12: 

Change  the  P458  flag 

to  a  1 2 1 . 

PS13: 

GO  TO  P473  (next  FNl. 

18.3.1). 

P473:  NEXT  FNl.18.3.1;  end  of  FNl.18.3.1,  GO  TO  P474. 

P474:  NEXT  FNl.18.3;  end  of  FNl.18.3,  GO  TO  P475. 

P475:  NEXT  FNl, 18;  end  of  FNl. 18,  GO  TO  FNl.19  (P476). 

FN1.19:  FOR  each  entry  on  the  P402  list  (i.e.,  for  each  user 

group  number  from  data  element  (11)  on  an  R2  list  entry): 

P476:  Start  a  list,  called  the  P476  list.  This  list  will 

resemble  the  P415  list,  except  that,  while  the  P415  list 
is  a  list  of  all  of  the  scheduling  information  (options) 
for  a  given  PI 77  list  entry  group,  the  P476  list  will 
contain  all  of  the  scheduling  information  for  a  given 
group  of  users  capable  of  performing  certain  tasks,  i.e., 
the  groups  identified  in  data  element  (11)  on  R2  list 
entries.  Generate  a  new  P476  list  each  time  P476  is 
executed;  retain  all  P476  lists  throughout  FNl. 

Place  the  value  in  the  P402  list  entry  for  this  iteration 
of  FNl.19  as  the  label  on  the  P476  list  generated  at  this 
time. 

At  the  top  of  each  P476  list  there  will  be  a  count  of  the 
number  of  entries  on  the  P476  list.  Start  this  data 
element  with  the  value  'O'. 

Each  P476  list  will  consist  of  a  series  of  entries.  Each 
entry  will  consist  of  7  data  elements.  Data  elements  (1) 
through  (5)  are  the  same  as  data  elements  (1)  through  (5) 
on  a  P415  list.  Data  element  (6)  consists  of  the  value 
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that  is  the  label  on  the  P415  list  from  which  the  P476 
list  entry  was  copied.  Data  element  (7)  will  be  a 
sequential  number  to  assign  a  unique  number  to  each  P476 
list  entry. 

P477:  Locate  the  P408  list  corresponding  to  the  P402  entry  for 
this  iteration  of  FN1.19. 

FN1.19.1:  FOR  each  ID4  on  the  P408  list  located  in  P477: 

FN1. 19.1,1:  FOR  'X'  iterations  (where  'X'  is  the  value  in  P233, 
i.e.,  the  number  of  entries  on  the  original  P 177  list): 

P478:  Is  there  a  P177  list  entry  with  the  value  of  'X1  for  this 
iteration  of  FNl. 16  as  its  data  element  (1)?  Yes  =  P479; 
No  =  P488  (next  FN1. 19.1.1) 

P479:  Locate  the  P415  list  with  the  value  of  'X'  for  this 
iteration  of  FNl.19.1.1  as  its  label. 

FN1. 19.1.1.1:  FOR  each  entry  on  the  P415  list  located  in  P479: 

P480:  Identify  the  employee  identifier  (ID4)  in  data  element  (1) 
of  the  P415  list  entry  for  this  iteration  of  FNl.  19. 1.1.1. 

P481:  Is  the  104  from  P480  the  same  as  the  104  for  this 

iteration  of  FNl. 19.1?  Yes  =  P482;  No  =  P487  (next 
FNl. 19. 1.1.1) 

P482:  Generate  a  new  P476  list  entry.  Use  the  entire  P415  list 
entry  (all  5  data  elements)  from  this  iteration  of 
FNl. 19. 1.1.1  as  data  elements  (1)  through  (5)  of  the  new 
P476  list  entry.  Use  the  value  of  'X'  for  this  iteration 
of  FNl. 19. 1.1  as  data  element  (6)  for  this  new  P476  list 
entry.  Add  '1'  to  the  data  element  at  the  top  of  the  P476 
list.  Enter  the  sum  in  the  data  element  at  the  top  of  the 
P476  list  as  data  element  (7). 

P483:  Identify  the  value  in  data  element  (4)  (whether  this  is 

the  1027  from  one  of  the  'already  scheduled1  tasks)  on  the 
newly  generated  P476  list  entry  for  this  iteration  of 
FNl. 19. 1.1.1.  Is  the  value  a  'Yes'  or  'No'?  Yes  =  P484; 
No  =  P486 

P484:  Enter  the  P476  list  entry  generated  in  P482  onto  the  top 
of  the  P476  list  generated  in  this  iteration  of  FNl. 19. 
(Note:  It  is  important  that  the  entry  be  put  on  the  top 
of  (i.e.,  in  front  of  all  other  entries)  on  the  P476  list 
in  order  that  scheduling  options  (ID27s)  that  include  the 
already  scheduled  tasks  will  be  given  higher  priority  than 
other  options  on  the  P476  lists.  The  other  options  on  the 
P476  lists  will  be  scheduling  options  for  the  same  time 
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period  as  the  already  scheduled  task  (where  the  time 
period  is  defined  by  the  P177  list  entry  group),  but  which 
are  not  performed  by  the  same  user  (employer  identifier 
(104))  and  therefore  are  scheduled  on  a  different  set  of 
DS27  data  and  therefore  have  a  different  ID27.) 

P485 :  GO  TO  P486  (next  FN1. 19. 1.1.1). 

P486:  Enter  the  P476  list  entry  generated  in  P482  onto  the 
bottom  of  (i.e.,  after  all  other  entries)  of  the  P476 
list  generated  in  this  iteration  of  FN1.19). 

P487:  NEXT  FNl, 19. 1.1.1;  end  of  FNl. 19. 1.1.1,  GO  TO  P488. 

P488:  NEXT  FNl.19.1.1;  end  of  FNl. 19. 1.1,  GO  TO  P489. 

P489:  NEXT  FNl. 19.1;  end  of  FNl. 19.1,  GO  TO  P490. 

P490:  NEXT  FNl. 19;  end  of  FNl. 19,  GO  TO  P991. 


P491 : 

(From  P1025):  Store  a  flag,  called  the  P491  flag.  This 
flag  will  indicate  whether  the  search  for  scheduling 
options  for  this  iteration  of  FNl  is  on  its  first 
iteration  at  this  point  in  the  program  logic.  Store  the 
value  of  'A'  in  this  flag. 

P492: 

Start  a  list,  called  the  P492  list.  This  list  gives  the 
status  of  the  search  for  scheduling  options  for  each  task 
on  the  R2  list  from  PI  for  this  iteration  of  FNl.  Each 
entry  on  the  P492  list  consists  of  11  data  elements: 

(1) 

A  requirement  application  identifier  (105), 
uniquely  identifying  a  task. 

(2) 

A  code  (1-3)  indicating  whether  the  task  is  a 
currently  being  scheduled,  already  scheduled  or 
future  scheduled  task. 

(3) 

A  flag  indicating  the  point  in  the  search  for 
scheduling  options  at  which  this  task  is  in  the 
program  logic. 

(4) 

A  value  indicating  the  number  of  entries  on  the 
P476  list  for  this  task.  This  value  is  at  the  top 
of  each  P476  list. 

(5) 

A  counting  number  indicating  the  point  in  the  P476 
list  at  which  the  search  for  scheduling  options  is 
for  this  task  at  this  point  in  the  program  logic. 
This  number  identifies  the  value  in  data  element 
(7)  on  the  P476  list  entry.  This  counter  will  be 
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left  blank  if  the  code  in  data  element  (9a)  is  'NC' 
(No  Change). 

(6)  A  number  (l-'X*,  where  'X'  is  the  number  of  entries 
on  the  P492  list)  assigned  to  each  P492  list  entry 
so  that  is  has  a  unique  value. 

(7)  A  counting  number  indicating  the  point  on  the  P361 
list  identified  in  data  element  (6)  at  which  the 
scheduling  option  most  recently  generated  for  this 
task  began.  Left  blank  if  'NC‘  code  is  in  data 
element  (9a). 

(8)  Whether  this  task  has  reached  the  end  of  a  search 
for  scheduling  options.  Answers:  Yes/No 

(9a)  Code  of  1 M 1 ,  1 B 1  or  'NC'  indicating  where  the  next 
search  for  scheduling  options  for  this  task  should 
take  place,  i.e.,  it  should: 

0  Begin  from  the  Marker  in  data  element  (7), 
as  indicated  by  a  code  of  1 M ' ; 

0  Begin  at  the  Beginning  of  all  scheduling 

options  for  this  task,  i.e.,  with  the  first 
entry  on  the  P476  list  and  the  first  entry  on 
the  corresponding  P361  list  for  this  task,  as 
indicated  by  a  code  of  1 B 1 ;  or, 

0  Not  change  the  scheduling  option  identified 
in  a  previous  search  for  scheduling  options 
for  this  task  as  indicated  by  the  code  of 
'NC' . 

(9b)  If  'NC'  is  the  value  entered  in  data  element  (9a), 
then  (9b)  indicates  whether  the  previous  scheduling 
option  was  from  a  P528  (code  'a')  list  or  a  P529 
(code  * b ' )  list  should  also  be  indicated. 

(10)  Whether  this  task  is  one  for  which  there  is  only 
one  scheduling  option,  i.e.,  it  is  an  'already 
scheduled'  task  (code  (2)  in  data  element  (2) 
above)  for  which  the  schedule  was  specified  by  the 
user.  Answers:  Yes/No 

FNl. 20:  FOR  each  105  on  the  P7  list: 

P493:  Locate  the  entry  on  the  R2  list  from  PI  with  the  value  of 

the  ID5  for  this  iteration  of  FNl. 20  in  data  element  (3). 


P494:  Identify  the  code  (1-3)  in  data  element  (2)  of  the  R2  list 
entry  from  P493. 
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P495:  Identify  the  value  in  data  element  (II)  (task  performer 
group)  of  the  R2  list  entry  from  P493. 

P496:  Locate  the  P476  list  entry  with  the  value  from  P495  as  its 
label . 

P497:  Identify  the  value  in  the  1  data  element  at  the  top  of  the 
P476  list  located  in  P496,  i.e.,  the  total  number  of 
entries  on  this  P476  list. 

P498:  Generate  a  partial  P492  list  entry.  Put  the  ID5  from  this 
iteration  from  FN1.20  in  data  element  (1);  the  code  from 
P494  in  data  element  (2);  the  flag  of  '1*  in  data  element 
(3);  and,  the  value  from  P497  in  data  element  (4).  If 
the  code  from  P494  was  a  '1'  or  a  *3',  place  the  value  of 
'1‘  in  data  elements  (5)  and  (7)  and  place  the  code  * B ‘ 
(beginning)  in  data  element  (9a).  If  the  P494  code  is 
'2',  leave  data  elements  (5)  and  (7)  blank  and  place  the 
code  'NC  in  data  element  (9a)  and  code  'a*  (P528  list)  in 
data  element  (9b).  Place  the  answer  'No1  in  data  element 
(8).  Data  element  (6)  should  be  a  unique  number  assigned 
to  each  P492  entry  beginning  with  '1'  (first  entry)  and 
ending  with  the  value  equal  to  the  total  number  of  P492 
list  entries  (on  the  last  entry  on  the  P492  list). 

P499:  Is  the  code  from  P494  a  '2'  (already  scheduled  task)?  Yes 
=  P500;  No  =  P503 

P500:  Identify  the  answer  (Yes/No)  in  data  element  (lOe) 

(whether  this  already  task's  schedule  was  specified  by  the 
user)  of  the  R2  list  entry  located  in  P493.  Is  the  answer 
a  'Yes'  or  'No'?  Yes  =  P5 01;  No  *  P503 

P501:  Put  the  answer  'Yes'  in  data  element  (10)  (whether  this  is 
a  user  specified  schedule)  of  the  newly  generated  P492 
list  entry. 

P502:  GO  TO  P504. 

P503:  Put  the  answer  'No'  in  data  element  (10)  of  the  newly 
generated  P492  list  entry. 

P504:  Is  the  code  from  P494  a  '1',  '2'  or  '3'?  1  =  P505;  2  = 

P507 ;  3  =  P509 

P505:  Put  the  newly  generated  P492  list  entry  on  a  temporary 
list  called  the  P505  list. 

P506:  GO  TO  P510  (next  FN1.20). 


P507:  Put  the  newly  generated  P492  list  entry  on  a  temporary 
list,  called  the  P507  list. 

P508:  GO  TO  P510  (next  FN1.20). 

P509:  Put  the  newly  generated  P492  list  entry  on  a  temporary 
list,  called  the  P509  list. 

P510:  NEXT  FN1.20;  end  of  FN1.20,  GO  TO  P511. 

P511:  Enter  the  entries  on  the  P507  list  onto  the  P492  list. 

P512:  Enter  the  entries  on  the  P505  list  onto  the  P492  list  at 

the  end  of  the  entries  already  on  the  P492  list. 

P513:  Enter  the  entries  on  the  P509  list  onto  the  P492  list  at 
the  end  of  the  entries  already  on  the  P492  list. 

P514:  Erase  the  P505,  P507  and  P509  lists. 

P515:  Start  a  list,  called  the  P515  list.  This  list  will 

contain  pairs  of  monthly  schedule  identifiers  (ID27s)  for 
each  pair  of  ID27 s  used  in  a  particular  "combination  of 
task  scheduling  options". 

P516:  Start  a  list,  called  the  P516  list.  This  list  will  be  the 
list  of  combination  of  task  scheduling  options  that  is 
currently  being  formed  in  a  given  search  for  scheduling 
options.  (Note:  A  combination  of  task  scheduling 
options  is  the  phrase  used  to  refer  to  a  particular  group 
of  scheduling  options  covering  one  or  more  of  the  tasks  in 
the  R2  list  from  PI.  Each  task  on  the  R2  list  from  PI  may 
have  a  scheduling  option  identified.  However,  it  is 
necessary  that  the  scheduling  options  for  different  tasks 
do  not  overlap,  i.e.,  do  not  use  the  same  calendar  time 
slots),  the  basis  for  selection  of  the  best  task 
scheduling  options  must  be  based  on  the  best  combination 
of  non-overl apping  task  scheduling  options.  In  the 
program  logic  that  follows,  the  program  first  identifies 
scheduling  options  for  each  task,  if  possible,  based  on 
certain  criteria.  (The  criteria  selected  depends  on  the 
flag  in  data  element  (3)  of  the  P492  list  entry  for  the 
task.)  As  a  scheduling  option  is  identified  for  each 
task,  the  calendar  time  slots  covered  by  that  schedule  are 
blocked  out  (on  the  P349  list  for  the  corresponding 
calendar  time  slots,  i.e.,  for  the  corresponding  PI 77  list 
entry  group)  so  that  they  cannot  be  used  for  any  other 
task  scheduling  options.  The  task  scheduling  option  thus 
generated  is  described  by  placing  information  about  the 
option  on  a  P528,  P 529  or  P530  list.  When  an  attempt  has 
been  made  to  identify  a  scheduling  option  for  all  tasks  on 
the  R2  list  from  PI,  the  combination  of  each  task 
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scheduling  option  is  examined  (using  the  data  describing 
this  combination  on  the  P516  list)  to  determine  if  it  is 
optimal,  e.g.,  fewest  number  of  interruptions,  fewest 
number  of  tasks  that  need  to  be  rescheduled,  etc.) 

The  P516  list  will  have  5  data  elements  at  the  top  of  the 
list  (before  the  entries  begin): 

(1)  A  count  of  the  number  of  entries  on  the  P516  list. 
Store  the  value  of  'O'  in  this  counter  at  this 
point. 

(2a)-(2d)  Four  counters,  called  the  (2a)  through  (2d) 

counters.  Fill  each  counter  with  the  value  of  'O'. 
These  counters  will  be  the  counters  of  the  number 
of  currently  being  scheduled  (2a),  already 
scheduled  (2b),  future  scheduled  (2c)  and  total 
(2d)  tasks  scheduled  in  the  combination  of  task 
scheduling  options  represented  by  the  current  P516 
list. 

(3a)-(3d)  The  same  as  (2a)  through  (2d),  except  these  are 
the  counters  for  the  not  scheduled  tasks  in  this 
combination  of  task  scheduling  options. 

(4)  A  count  of  the  number  of  time  slots  that  are  in 
incorrect  time  use  codes  for  the  entire  set  of  time 
slots  scheduled  for  this  combination  of  task 
scheduling  options.  Store  the  value  of  'O'  in  this 
counter . 

(5)  A  value  indicating  the  ratio  of  the  number  of  time 
slots  scheduled  to  the  total  calendar  time  slots 
required  to  schedule  them  (including  interruptions, 
scheduling  time  not  available  and  time  slots 
scheduled  for  tasks  not  in  this  iteration  of  FNl, 
etc. ) . 

(6)  A  value  indicating  the  number  of  P 1 7 7  list  entry 
groups  in  this  combination  of  task  scheduling 
options  which  have  tasks  scheduled  in  such  a  way 
that  the  calendar  time  for  scheduling  tasks  is 
more  than  twice  the  time  in  which  tasks  are 
scheduled. 

(7a)-(7j)  Ten  counters  representing  the  numbers  of 
various  types  of  tasks  that  will  need  to  be 
rescheduled  should  this  task  scheduling  option  be 
chosen.  See  the  P525a  through  P525j  counters. 
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The  entries  on  the  P516  list  consist  of  the  3-part  labels 
for  task  scheduling  options  given  in  the  P528,  P529  or 
P530  lists. 

P517:  Start  a  list,  called  the  P517  list.  This  will  be  an  exact 
replica  of  the  P516  list,  except,  while  the  P516  list  is 
the  combination  of  task  scheduling  options  as  the 
combination  is  being  formed,  the  P517  list  will  be  the 
best  combination  of  task  scheduling  options,  formed 
thus  far  in  the  search  for  combinations  of  task 
scheduling  options. 

P518:  Start  a  list,  called  the  P518  list.  This  list  will 
contain  information  about  the  combination  of  task 
scheduling  options  being  formed  in  the  P516  list  that  are 
scheduled  for  each  group  of  calendar  time  slots 
identified  by  a  P177  list  entry  group.  There  is  an  entry 
on  the  P518  list  for  each  P 1 7 7  list  entry  group,  i.e.,  the 
number  of  entries  on  the  list  is  equal  to  the  value  in 
P233.  Each  entry  on  the  P518  list  consists  of  8  data 
elements: 

(1)  A  sequential  counter  ('1*  to  'X',  where  ’X’  is  the 
value  from  P233)  equal  to  the  value  in  data  element 
(1)  of  the  corresponding  P177  list  entry. 

(2)  The  number  of  time  slots  in  this  P177  list  entry 
group,  i.e.,  the  value  in  data  element  (4)  of  the 
P177  list  entry  identified  in  data  element  (1) 
above. 

( 3a ) - ( 3d )  The  number  of  tasks  scheduled  in  this  P177  list 
entry  group  for  the  current  combination  of  task 
scheduling  options.  Data  elements  (3a),  (3b),  (3c) 
and  (3d)  are  the  counts  for  currently  being 
scheduled,  already  scheduled,  future  scheduled  and 
total  scheduled  tasks  respect i vely. 

(4a)-(4d)  The  same  as  (3a)  through  (3d),  except  that  this 
is  a  count  of  the  number  of  time  slots  scheduled 
rather  than  tasks  scheduled. 

(5)  Whether  the  first  time  slot  of  the  P177  list  entry 
group  identified  by  data  element  (1)  above  is 
filled  as  a  part  of  one  of  the  task  scheduling 
options  in  the  current  combination  of  task 
scheduling  options.  Answers:  Yes/or  blank,  where 
a  blank  means  'No'.  (Note:  The  answer  to  this 
question  must  be  'Yes'  for  this  to  be  a  valid 
combination  of  task  scheduling  options.  This  is 
because,  although,  in  attempting  to  schedule 
'employee  transport'  tasks  next  to  other  already 
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scheduled  'employee  transport*  tasks  for  the  same 
employee,  it  is  acceptable  to  reschedule  the 
already  scheduled  tasks  (if  the  schedule  for  these 
tasks  was  not  specified  by  the  user  and  if  this 
rescheduling  will  be  to  a  better  combination  of 
scheduling  options);  nevertheless,  one  of  the  tasks 
being  scheduled  in  this  iteration  of  FNl  must  be 
scheduled  to  begin  when  the  already  scheduled  task 
was  previously  scheduled  to  begin,  so  that  the 
employee  who  has  been  notified  of  the  already 
scheduled  tasks  on  a  Scheduling  Notice  (015)  begins 
a^  task  at  the  same  time  as  before  the  new  tasks 
were  scheduled  and  the  already  scheduled  tasks  were 
rescheduled.  This  enables  the  employee  to  begin  to 
participate  in  tasks  at  the  same  time  that  the 
employee  has  been  notified  that  his  participation 
in  tasks  will  begin.) 

The  latest  time  slot  scheduled  in  this  P177  list 
entry  group.  In  this  case,  the  time  slot  is 
identified  only  by  the  sequential  number  assigned 
to  each  of  the  time  slots  in  the  P177  list  group 
(i.e.,  the  number  assigned  to  data  element  (1)  of 
each  P349  list  entry  for  this  P177  list  entry 
group),  because  the  rest  of  the  information  about 
the  time  slot  is  known  from  other  lists.  This 
information  is  used  to  measure  whether  the 
combination  of  task  scheduling  options  has  tasks 
scheduled  in  a  P177  list  group  in  such  a  way  that 
they  are  so  spread  out  that  there  is  more  than 
twice  the  distance  between  tasks  as  there  are  time 
slots  required  for  scheduling  the  tasks.  If  this 
is  found  to  be  true,  then  the  combination  of  task 
scheduling  options  is  not  valid,  because  it  would 
lead  to  too  much  loss  of  productive  time  by  the 
employee  who  is  to  participate  in  the  task. 

The  information  needed  to  determine  if  the  employee 
in  the  employee  transport  tasks  in  this  iteration 
of  FNl  has  been,  by  the  current  combination  of  task 
scheduling  options,  scheduled  for  tasks  that  last 
more  than  4-1/2  hours  or  more  (18  time  slots) 
without  a  break.  This  type  of  combination  of  task 
scheduling  options  would  be  found  not  to  be  valid 
because  the  employee  could  not  be  expected  to  be 
participating  in  tasks  for  this  length  of  time 
without  a  break.  Whether  this  overly  extended 
scheduling  of  an  employee  has  occurred  is 
determined  by  checking  the  P349  list  for  a  given 
P177  list  entry  group  for  continuous  tentatively 
scheduled  time  slots  (i.e.,  checking  data  element 
(7)  on  each  entry  of  the  P349  list  corresponding  to 


the  P 17 7  list  entry  group),  if  the  value  in  data 
element  (4d)  of  the  P518  list  entry  for  the 
correspond ing  P177  list  entry  group  exceeds  '17' , 
However,  to  check  whether  the  total  continuous 
scheduling  of  an  employee  exceeds  17  time  slots 
when  tasks  are  scheduled  for  calendar  time  slots 
represented  by  different  P177  list  groups,  it  is 
necessary  to  first  determine  if  the  P177  list  entry 
groups  are  continuous  (i.e.,  the  calendar  time  slot 
where  one  group  begins  is  immediately  after  the 
time  slot  where  the  previous  group  ended)  and,  if 
so,  to  add  together  the  continuously  scheduled  time 
slots  at  the  end  of  the  first  P177  list  entry  group 
to  the  continuously  scheduled  time  slots  at  the 
beginning  of  the  next  P177  list  entry  group. 

If  more  than  '17  time  slots  have  been  scheduled 
cont inusous ly,  the  program  inserts  extra 
'interruptions'  (i.e.,  the  code  of  'I'  indicating 
that  this  time  slot  cannot  be  scheduled!)  after 
(and/or  before)  the  continuous  string  of 
tentatively  scheduled  time  slots.  The  information 
in  data  elements  (7a)  through  (7d)  of  the  P518  list 
entries  corresponding  to  the  first  and  second  P 1 7 7 
list  entry  groups  enables  the  determination  to  be 
made  of  whether  the  extra  interruption  time  slots 
need  to  be  inserted  and,  if  so,  whether  this  has 
already  been  done.  Data  element  (7e)  indicates 
whether  more  than  17  time  slots  on  the  single 
P349  list  correspond ing  to  this  P518  have  been 
previously  found  to  have  been  tentatively  scheduled 
and  interruptions  have  already  been  added.  Data 
elements  (7c)  through  (7e)  avoid  requiring  the 
program  to  attempt  to  insert  the  extra  interruption 
flag  more  than  once. 

(a)  Whether  the  start  time  slot  information  in 
data  element  (2)  for  the  P177  list  entry 
group  represented  by  this  entry  on  the  P518 
list  begins  immediately  after  the  end  time 
slot  for  the  previous  P177  list  entry  group 
(i.e.,  the  previous  P518  list  entry)  as  shown 
in  data  element  (3),  of  that  P177  list  entry. 
Answers:  Ves/No 

(b)  Whether  the  end  time  slot  of  the  P177  list 
entry  represented  by  this  entry  on  the  P518 
list  (as  shown  in  data  element  1 3 )  of  the 

P 1 7 7  list  entry)  ends  immediately  before  the 
start  time  slot  (shown  in  data  element  (2)) 
of  the  next  P177/P518  list  entry. 
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(c)  If  (7a)  was  'Yes',  whether  2  extra 
'interruption'  flag  have  been  added  to  the 
P349  list  corresponding  to  this  P518  list 
indicating  that  2  time  slot  are  not  to  be 
scheduled,  thus  ensuring  that  the  combination 
of  the  two  P349  lists  do  not  result  in 
scheduling  more  than  '17'  time  slots  without 
a  break.  Answers:  Yes/No 

(d)  If  (7b)  was  'Yes',  whether  2  extra 
interruptions  flags  have  been  added. 

Answers:  Yes/No 

(e)  Whether  2  extra  'interruption'  time  slots 
have  been  added  to  address  the  problem  that 
more  than  17  time  slots  have  been 
continuously  scheduled  on  the  P349  list 
corresponding  to  this  P518  list. 

(f)  Whether  the  calendar  time  for  tentative 
scheduling  of  tasks  on  the  P 1 7 7  list  entry- 
group  represented  by  the  P518  list  entry  is 
more  than  twice  the  time  for  which  tasks  are 
scheduled.  This  data  element  considers  the 
time  between  the  scheduling  of  tasks  during 
which  the  employee  would  have  to  wait. 
Answers:  Yes/No 

P519:  Generate  entries  for  the  P518  list.  Generate  a  P518  list 
entry  for  each  entry  on  the  P177  list.  Fill  in  data 
elements  (1)  and  (2)  on  each  P518  list  entry  with  the 
value  in  data  elements  (1)  and  (4)  on  the  corresponding 
P177  list  entry.  Set  the  values  in  data  elements 
(3a)-(3d),  (4a)-(4d),  and  (6)  to  be  ‘O'.  Leave  the 
remaining  data  elements  on  the  P518  list  entries  blank  at 
this  time. 

P520:  Start  a  counter,  called  the  P520  counter,  with  the  value 
'0'  in  it.  This  counter  will  be  the  count  of  the  number 
of  time  slots  tentatively  scheduled  for  a  task  as  it  is 
tentatively  scheduled. 

P521:  Start  a  counter,  called  the  P521  counter,  with  the  value 
of  ’0’  in  it.  This  counter  will  be  the  count  of  the 
number  of  time  slots  tentatively  scheduled  for  a  task 
since  the  last  interruption. 

P522:  Start  a  counter,  called  the  P522  counter,  with  the  value 
of  ’0’  in  it.  This  will  be  a  counter  of  the  number  of 
interruptions  in  the  scheduling  of  a  task  as  it  is 
tentatively  scheduled. 
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P523: 


P524: 


P525  : 


Start  a  counter,  called  the  P523  counter,  with  the  value 
of  'O'  in  it.  This  will  be  a  counter  of  the  number  of 
time  slots  that  are  interruptions  in  the  scheduling  of  a 
task  as  it  is  tentatively  scheduled. 

Start  a  counter,  called  the  P524  counter,  with  the  value 
'O'.  This  counter  will  be  the  count  of  the  number  of 
time  slots  that  are  interruptions  since  the  beginning  of 
the  last  interruption. 

Start  a  series  of  10  counters,  called  the  P525a  through 
P525j  counters,  each  with  a  value  of  'O'.  These  are  the 
counters  of  the  number  of  tasks  having  various 
characteri sti cs  that  will  have  to  be  rescheduled  if  a 
task  is  scheduled  in  the  way  it  is  tentatively  scheduled. 

P525a  is  the  counter  for  the  number  of  Reminder 
Notice  tasks  without  standard  restrictions  that 
need  to  be  rescheduled  if  this  scheduling  option 
was  chosen; 

P525 b  is  the  recommended  tasks  without  standard 
restrictions  that  are  undated  that  would  need  to  be 
rescheduled; 

0  P525c  is  the  mandatory  undated  tasks  without 

standard  restrictions; 

°  P525d  is  the  Reminder  Notice  tasks  with  standard 

restrictions; 

P525e  is  the  recommended  undated  tasks  with 
standard  restrictions; 

0  P525 f  is  the  mandatory  undated  tasks  with  standard 

restrictions; 

P 525 g  is  the  recommended  dated  tasks  with  standard 
restrictions; 

u  P525h  is  the  mandatory  dated  tasks  with  standard 

restrictions; 

0  P525i  is  the  total  number  of  dated  non-Reminder 

Notice  tasks  that  would  be  rescheduled,  i.e.,  the 
sum  of  the  P525 g  and  P525h;  and 

'  P525j  is  the  total  number  of  tasks  rescheduled, 

i.e.,  the  sum  of  the  P525a  through  P525h  counters. 

These  counts  are  maintained  in  order  to  enable  assigning 
higher  priority  to  scheduling  options  that  require 
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rescheduling  of  the  fewest  numbers  of  difficult  to 
reschedule  tasks. 

P526:  Generate  the  format  for  a  series  of  lists,  called  the  P526 
lists.  The  P526  lists  store  the  task  identifier  (1023) 
for  the  tasks  that  need  to  be  rescheduled  if  another  task 
is  scheduled  in  the  way  it  is  tentatively  scheduled.  The 
P526  list  has  a  3-part  label  consisting  of:  part  (1)  an 
105;  part  (2)  a  P177  list  entry  group  number;  and,  part 
(3)  a  code  of  either  ‘ b 1  (currently  being  formed'  P526 
list,  i.e.,  the  P526  list  formed  while  task  scheduling 
options  are  identified)  or  ' c '  ('best  so  far'  P526  list, 
i.e.,  the  P526  list  corresponding  to  the  best  scheduling 
option  for  the  task).  Entries  on  the  P526  list  consist  of 
1023s.  These  1023s  are  put  on  DL39,  if  the  scheduling 
option  to  which  the  P526  list  corresponds  is  chosen. 

P527:  Start  a  counter,  called  the  P527  counter,  with  the  value 
‘0‘.  This  is  the  counter  of  the  number  of  time  slots 
scheduled  in  not  the  correct  time  use  code  (i.e.,  not  the 
time  use  code  (CTll)  preferred  by  the  user  for  a  time  slot 
as  specified  on  the  DS26  and  DS27  data)  if  a  task  is 
scheduled  in  the  way  it  is  tentatively  scheduled. 

P528:  Generate  the  format  for  a  series  of  lists,  called  the  P528 
lists.  The  P528  lists  are  referred  to  as  task  scheduling 
options  lists,  because  they  represent  a  particular  option 
for  scheduling  a  particular  task.  The  P529  and  P530 
series  of  lists  are  also  task  scheduling  option  lists 
and  have  the  exact  same  format  as  the  P528  lists.  The 
three  types  of  task  scheduling  option  lists  differ  in 
these  ways: 

The  P528  lists  consist  of  the  one  scheduling  option 
for  each  ‘already  scheduled*  task  that  is  an 
exact  copy  of  the  way  in  which  this  already 
scheduled  task  was  previously  scheduled; 

The  P529  lists  consist  of  all  other  scheduling 
options  as  the  options  are  being  formed;  and, 

0  The  P530  lists  consist  of  the  scheduling  options 
for  all  tasks  in  a  combination  of  task  scheduling 
options  for  the  combination  that  has  been  found  to 
be  the  best  combination  of  task  scheduling 
options  so  far  in  the  search  for  combinations  of 
task  scheduling  options  (as  shown  on  the  P517 
list). 


The  generation  and  retention  of  information  on  these  3 
types  of  task  scheduling  option  lists  is  as  follows: 
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There  must  be  one,  and  only  one,  P528  list  for  each 
'already  scheduled'  task  in  this  iteration  of  FNl 
(i.e.,  each  task  on  the  P26  list); 

0  The  P528  lists  are  retained  throughout  FNl; 

The  P529  lists  are  erased  after  it  is  determined 
that  a  new  P529  list  should  be  generated  (i.e., 
there  is  a  code  of  'NC'  (No  Change)  in  data  element 
(9)  of  the  P492  list  entry  for  the  task); 

0  The  P528  and  P529  lists  may  be  copied  over  onto  the 
P530  lists,  if  it  is  determined  that  the 
combination  of  task  scheduling  options  shown  on 
the  current  P529  lists  (or  combination  of  P529  and 
P528  lists;  a  given  combination  of  task  scheduling 
options  can  consist  of  a  P529  or  a  P528  list  for 
each  task  in  the  combination)  are  better  than  the 
current  combination  of  task  scheduling  options 
shown  on  the  current  P530  list; 

0  The  P530  lists  are  retained  throughout  FNl  or  until 
a  better  combination  of  task  scheduling  options  are 
found ; 

J  There  may  be  one  P529  and/or  a  P530  list  for  each 
task  in  this  iteration  of  FNl,  i.e.,  each  task  on 
the  R2  list  from  PI  (or,  put  another  way,  each  task 
on  the  P7  list).  However,  only  'already  scheduled' 
tasks  must  have  a  P529  and  P530  list;  'currently 
being  scheduled'  and  'future  scheduled'  tasks  will 
have  P529  lists  only  if  it  is  possible  to  identify 
a  scheduling  option  for  the  task  and,  at  any  point 
in  time,  will  have  a  P530  list  only  if  the  task  was 
scheduled  in  the  best  combination  of  task 
scheduling  options  found  at  that  point  in  time. 

Each  P528,  P529  and  P530  list  has  a  3  part  label:  Part 
(1)  is  the  requirement  application  identifier  (ID5) 
identifying  the  task  for  which  this  is  the  scheduling 
option.  Part  (2)  consists  of  the  P177  list  entry  group 
number  from  which  this  option  was  drawn.  Part  (3) 
consists  of  a  code  indicating  whether  this  is  a  P528  list 
(code  'a'),  a  P529  list  (code  ' b * ) ,  or  a  P530  list  (code 
’C). 

Each  P528,  P529  and  P530  list  contains  13  data  elements  at 
the  top  of  the  list  (before  the  entries  begin): 

(1)  A  code  (1-3)  indicating  that  this  is  a  currently 
being  scheduled,  already  scheduled  or  future 
scheduled  task 
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( 2 ) - ( 4 ) The  value  in  the  P520,  P522  and  P523  counters  as  of 
the  last  time  slot  scheduled  for  the  task 

(5a)-(5j)  The  value  in  the  P525a  through  P525j  counters  as 
of  the  last  time  slots  scheduled  for  the  task 

(6)  The  value  in  the  P527  counter  as  of  the  last  time 
slot  scheduled 

(7)  Whether  this  task  scheduling  option  was  scheduled 
on  a  0S27  data  set  that  is  for  one  of  the  ID27 s  (or 
pairs  of  ID 2 7s )  that  are  used  for  the  already 
scheduled  tasks  in  this  iteration  of  FNl. 

(8)  The  employee  identifier  (ID4)  for  the  user 
scheduled  to  perform  this  task 

(9)  The  time  use  code  (CT11)  for  the  task 

(10)  The  task  type  code  (CT8)  for  the  task 

(11)  Whether  this  task  has  any  restrictions  and,  if  so, 
whether  they  are  standard,  special  or  both  type  of 
restrictions 

(12)  The  number  of  time  slots  required  to  schedule  this 
task 

(13)  The  task  identifier  (ID23)  for  this  task 

Each  P528,  P529  and  P530  list  consists  of  'X'  number  of 
entries,  where  'X'  is  equal  to  the  number  of  time  slots 
scheduled  for  the  task  in  this  task  scheduling  option. 
(Note:  'X1  is  the  value  in  the  P520  counter  at  the  end  of 
the  scheduling  of  the  task;  because  an  extra  time  slot  is 
added  to  the  time  slots  required  to  schedule  a  task  for 
each  interruption  in  the  scheduling  of  the  task,  the  value 
in  the  P529  counter  will  not  always  be  the  same  as  the 
number  of  time  slots  required  to  schedule  the  task  and 
will,  therefore,  not  always  be  the  same  even  for  the  same 
task . ) 

Each  entry  on  the  P528,  P529  or  P530  list  will  consist  of 
8  data  elements  about  a  time  slot: 

(1)  A  sequential  number  of  the  time  slot.  (Note:  This 
is  not  the  same  as  the  time  slot  number  (1-96); 
instead,  it  is  a  sequential  number  derived  by 
numbering  the  time  slots  of  a  P177  list  entry  group 
beginning  with  a  '1*  for  the  first  time  slot  in  the 
P177  list  entry  group  and  ending  with  the  number  in 
P505  for  the  last  time  slot  in  the  P177  list  entry 
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group.  This  sequential  number  is  derived  from  data 
element  (1)  of  each  entry  on  the  P361  list.) 

(2)  Time  slot  information.  In  this  case,  time  slot 
information  consists  of  three  parts:  (1)  a  monthly 
schedule  identifier  (ID27),  (2)  a  date  (1-31),  and 
(3)  a  time  slot  number  (1-96). 

( 3 )  - ( 7 )  The  values  from  the  P520  through  P524  counters  as 

of  the  tentative  scheduling  of  this  time  slot. 

(8)  Whether  this  time  slot  was  scheduled  for  the 

preferred  time  use  (C Til )  specified  by  the  user. 
Answers:  Yes/No. 

P529:  Generate  a  list  format  for  the  lists  called  the  P529 
lists.  These  lists  are  an  exact  replica  of  the  P528 
lists,  except  that  they  will  be  used  for  entering 
scheduling  option  information  as  the  scheduling  options 
are  being  formed. 

P530:  Generate  a  list  format  for  the  lists  called  the  P530 
lists.  These  lists  are  an  exact  replica  of  the  P528 
lists,  except  that  they  will  be  used  to  enter  the  best 
scheduling  options  identified  at  any  point  in  the  search 
for  scheduling  options. 

FN1.21:  FOR  each  task  identifier  (1023)  on  the  P26  (already 
scheduled  tasks)  list: 

P531:  Identify  the  entry  on  the  R 2  list  from  Pi  that  contains 

the  ID23  for  this  iteration  of  FN1.21  in  data  element  (1). 

P532:  Identify  the  requirement  application  identifier  (105)  in 
data  element  (3)  of  the  R2  list  entry  from  P531. 

P533:  Begin  to  generate  a  P528  list  for  this  task.  Fill  in  part 

(1)  of  the  label  with  the  105  from  P532.  Fill  in  part 

(2)  with  the  P 17 7  list  entry  group  that  is  data  element 
(2)  on  the  P26  list  entry  for  this  iteration  of  FN1.21  (as 
expanded  in  P175).  Fill  in  part  (3)  with  the  code  ‘a1. 
Fill  in  the  following  data  elements  at  the  top  of  the 
P528  list:  Data  element  (1)  is  the  code  '2'.  Fill  in  all 
of  the  8  counters  from  P525  that  are  in  data  element  (5) 
at  the  top  of  the  P528  list  with  a  'O'.  The  answer  in 
data  element  (7)  is  'Yes'.  Data  elements  (9),  (10),  (11) 
and  (12)  should  be  the  value  in  data  elements  (7),  (6), 
(4b)  and  (9)  of  the  R2  list  entry  from  P531.  Fill  in  data 
element  (13)  of  the  data  elements  at  the  top  of  the  P528 
list  with  the  1023  for  this  iteration  of  FN 1.21. 

P534:  Identify  the  value  in  data  element  (11)  (task  performer 
group)  of  the  R2  list  entry  from  P531. 


STEP  F4A-3 


P535:  Locate  the  P476  list  with  the  value  from  P534  as  its 
label . 

FNl.21.1:  FOR  each  entry  on  the  P476  list  located  in  P535: 

P536:  Identify  the  employee  identifier  (ID4)  in  data  element  (1) 
of  the  P476  list  entry  for  this  iteration  of  FNl.21.1. 
Place  this  in  data  element  (8)  on  the  newly  generated  P528 
list  for  this  iteration  of  FNl.21  (as  started  in  P533). 

P537:  Identify  the  first  monthly  schedule  identifier  (ID27)  in 
data  element  (2)  of  the  P476  list  entry  for  this  iteration 
of  FNl.21.1. 

P538:  Identify  the  second  1027  in  data  element  (3)  of  the  P476 
list  entry  for  this  iteration  of  FNl.21.1. 

P539:  Locate  the  P361  list  with  the  label  consisting  of  the 

value  from  data  element  (2)  of  the  P26  list  entry  for  this 
iteration  of  FNl.20.1  (part  (1))  and  the  ID5  from  P532 
(part  (2)). 

P540:  Identify  the  value  in  data  element  (4)  (number  of  time 
slots  in  the  P177  list  entry  group  described  by  the  P361 
list)  of  the  4  data  elements  at  the  top  of  the  P361  list 
located  in  P539. 

P541:  Identify  the  start  time  slot  information  in  data  element 
(10a)  of  the  R2  list  entry  located  in  P531. 

P542:  Identify  the  end  time  slot  information  in  data  element 
(10b)  of  the  R2  list  entry  located  in  P531. 

P543:  Is  the  1027  that  is  part  (1)  of  the  P541  time  slot 

information  the  same  as  the  1027  from  P537?  Yes  =  P544; 

No  =  P571  (next  FNl.21.1) 

P544:  Is  the  1027  that  is  part  (2)  of  the  P542  time  slot 

information  the  same  as  the  1027  from  P537?  Yes  =  P545; 

No  =  P571  (next  FNl.21.1) 

P545:  Identify  the  first  entry  on  the  P361  1 i r t  located  in  P539. 

P546:  Start  a  counter,  called  the  P546  counter.  Fill  the 

counter  with  the  value  in  data  element  (4)  (day  of  the 
month)  of  the  time  slot  information  on  the  first  P361 
list  entry  (as  located  in  P545). 

P547:  Start  a  counter,  called  the  P547  counter.  Fill  the 

counter  with  the  value  in  data  element  (5)  (time  slot 
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P548: 


FN1.21 
PS49: 
P550: 
P551 : 
P552: 

P553: 


P554: 

P555 : 


P556: 

P557: 

P558: 

P559: 


number)  of  the  time  slot  information  on  the  P361  list 
entry  from  P545. 

Generate  a  flag,  called  the  P548  flag.  Store  the  value  of 
*1'  in  the  P548  flag,  thereby  indicating  that  FNl.21.1.1 
should  use  the  first  DS27  data  (i.e.,  the  DS27  data 
corresponding  to  the  ID27  from  P537),  not  the  second  DS27 
data  (identified  in  P538). 

.1.1:  FOR  each  entry  on  the  P361  list  located  in  P539: 

Is  the  P548  flag  a  *1'  or  a  *2'?  Yes  =  P550;  No  =  P552 

Locate  the  0S27  data  corresponding  to  the  ID27  identified 
in  P537. 

GO  TO  P552. 

Locate  the  DS27  data  corresponding  to  the  ID27  identified 
in  P538. 

Locate  the  time  slot  on  the  DS27  data  for  this  iteration 
of  FNl.20.1.1  (i.e.,  the  DS27  data  from  P550  or  P552)  that 
is  for  the  day  of  the  month  with  the  value  in  the  P546 
counter  and  the  time  slot  number  with  the  value  in  the 
P547  counter. 

Is  the  time  slot  from  P553  already  scheduled  with  a  task 
having  the  task  identifier  (ID23)  for  this  iteration  of 
FN1.21?  Yes  =  P561 ;  No  =  P555 

Ooes  the  P520  counter  (time  slots  tentatively  scheduled) 
contain  a  value  greater  than  ‘O’?  Yes  (i.e.,  the  time 
slot  in  this  iteration  of  FNl.21.1.1  is  an  interruption  of 
the  scheduling  of  the  already  scheduled  task  in  this 
iteration  of  FN 1.21)  =  P556;  No  (i.e.,  the  beginning  of 
the  scheduling  of  this  already  scheduled  task  has  not  yet 
been  reached)  =  P567  (next  FNl.21.1.1) 

Set  the  P521  counter  (number  of  time  slots  scheduled  since 
the  last  interruption)  to  be  'O'. 

Is  the  value  in  the  P524  counter  (number  of  time  slots 
that  are  interruptions  since  the  start  of  the  last 
interruption)  equal  to  'O'?  Yes  =  P558;  No  =  P559 

Add  '1*  to  the  P522  counter  (number  of  interruptions). 

Add  *  1  *  to  the  P524  counter  and  to  the  P523  counter 
(number  of  time  slots  that  are  interruptions). 


P560:  GO  TO  P567  (next  FNl.22.1.1). 
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P561:  Add  '1*  to  the  P520  counter  (time  slots  tentatively 

scheduled)  and  the  P521  counter  (time  slots  tentatively 
scheduled  since  the  last  interruption). 

P562:  Set  the  P524  counter  (number  of  time  slots  that  are 
interruptions  since  the  beginning  of  the  last 
interruption)  to  be  '0*. 

P563:  Using  the  DS27  data  for  this  iteration  of  FN 1.21.1.1, 
compare  the  preferred  time  use  code  (CT11)  and  the 
actual  time  use  code  (CT11)  for  this  task  (as  entered  in 
data  element  (9)  of  the  P528  list  generated  in  this 
iteration  of  FN1.21)  for  the  time  slot  in  this  iteration 
of  FN 1.21. 1.1.  Are  they  the  same?  Yes  =  P565;  No  =  P564 

P564:  Add  *  1  *  to  the  P527  counter  (number  of  time  slots  with 
incorrect  time  use  codes). 

P565:  Add  an  entry  to  the  P528  list  generated  in  this  iteration 
of  FN 1 . 21  (started  in  P533).  Fill  in  data  element  (1)  of 
the  new  P528  list  entry  with  the  value  in  data  element  (1) 
of  the  P361  list  entry  for  this  iteration  of  FNl.21.1.1. 
Fill  in  data  element  (2)  (time  slot  information)  with  the 
1027  for  this  iteration  of  FNl.21.1.1  (part  (1))  and  the 
date  (part  (2))  and  time  slot  number  (part  (3))  in  data 
elements  (4)  and  (5),  respectively,  of  the  P361  list  entry 
for  this  iteration  of  FNl.21.1.1.  Fill  in  data  elements 
(3)  through  (7)  with  the  values  in  the  P520  through  P524 
counters.  Fill  in  data  element  (8)  with  the  answer  given 
in  P563. 

P566:  Add  1 1 ‘  time  slot  to  the  P546  and  the  P547  counters,  and, 
if  applicable,  change  the  flag  in  P548.  To  do  this  follow 
the  Processing  Substeps  (PS)  given  in  P472  with  the 
following  exceptions: 

The  P457  counter  and  the  P456  counter  should  be  the 
P547  and  the  P546  counters  respectively. 

0  P473  should  be  P567. 

u  PS5  should  read:  "Identify  the  value  in  data 

element  (2)  (year)  and  data  element  (3)  (month)  of 
the  P361  list  entry  for  this  iteration  of 
FNl.21.1.1." 

0  The  P458  flag  should  be  the  P548  flag. 

P567 ;  NEXT  FNl.21.1.1;  end  of  FNl.21.1.1,  60  TO  P568. 

P568:  Complete  data  elements  (2),  (3),  (4)  and  (6)  at  the  top 
of  the  newly  generated  P528  list  for  this  iteration  of 
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FN 1 .21  (started  in  P533)  with  the  current  values  in  the 
P520,  P522,  P523  and  P527  counters,  respectively. 

P569:  Set  the  value  in  the  P520  through  P525  and  P527  counters 
to  'O' . 

P57Q:  NEXT  FN1.21;  end  of  FN1.21,  GO  TO  FNl.22  (P571). 

FN1.22:  FOR  each  entry  on  the  P518  list  (the  list  of 

information  about  P177  list  entry  groups  for  a  combination 
of  task  scheduling  options): 

P571:  Identify  the  P177  list  entry  group  number  in  data  element 

(1)  of  the  P518  list  entry  for  this  iteration  of  FNl.22. 

P572:  Is  there  a  P177  list  entry  with  the  value  in  P571  in  data 
element  (1)?  Yes  =  P573;  No  =  P602  (next  FNl.22) 

P673:  Locate  the  P177  list  entry  with  the  number  in  P571  in  data 
element  (1). 

P574:  Is  the  P518  list  entry  for  this  iteration  of  FNl.22,  the 
first  entry  on  the  P518  list?  Yes  =  P575;  No  =  P577 

P575:  Place  the  answer  'No'  in  data  element  (7a)  of  the  P518 
list  entry  for  this  iteration  of  FNl.22. 

P575:  GO  TO  P588. 

P577:  Start  a  counter  with  the  value  '1'. 

P578:  Derive  the  value  that  is  equal  to  the  value  identified  in 
P571  minus  the  value  in  the  P577  counter. 

P579:  Is  there  a  P 1 7 7  list  entry  with  the  value  derived  in  P578 
as  its  data  element  (1)?  Yes  =  P582;  No  =  P580 

P580:  Add  '1'  to  the  P577  counter. 

P581 :  GO  TO  P578. 

P582:  Locate  the  PI 77  list  entry  with  the  value  derived  in  P578 
as  its  data  element  (1). 

P583:  Identify  the  end  time  slot  information  in  data  element 
(3)  of  the  P 1 7 7  list  entry  located  in  P582. 

P584:  Identify  the  start  time  slot  information  in  data  element 

(2)  of  the  P177  list  entry  located  in  P573. 


P585:  Identify  the  time  slot  that  is  derived  by  subtracting  '1 
time  slot  from  the  time  slot  information  in  P584.  To  do 
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this  follow  the  Processing  Substeps  (PS)  given  in  P226, 
except : 

0  P226  should  be  P585. 

0  P212  should  be  P584. 

0  P227  should  be  P586. 

P586:  Is  the  time  slot  derived  in  P585  equal  to  the  time  slot 

identified  in  P583?  Yes  =  P575;  No  =  P587 

P587:  Place  the  answer  'Yes'  in  data  element  (7a)  of  the  P518 
list  entry  for  this  iteration  of  FNl.22. 

P588:  Is  the  P518  list  entry  for  this  iteration  of  FNl.22  the 
last  entry  on  the  P5I8  list?  Yes  =  P589;  No  =  P591 

P589:  Place  the  answer  'No*  in  data  element  (7b)  of  the  P581 
list  entry  for  this  iteration  of  FNl.22. 

P590:  GO  TO  P602  (next  FNl.22). 

P591:  Start  a  counter  with  the  value  '1'. 

P592;  Derive  the  value  that  is  equal  to  the  value  identified  in 
P571  plus  the  value  in  the  P591  counter. 

P593:  Is  there  a  PI 7 7  list  entry  with  the  value  oerived  in  P592 
as  its  data  element  (1)?  Yes  =  P596;  No  =  P594 

P594:  Add  '1'  to  the  P591  counter. 

P595 :  GO  TO  P592. 

P596:  Locate  the  P 1 7 7  list  entry  with  the  value  derived  in  P592 
as  its  data  element  (1). 

P 59 7 :  Identify  the  start  time  slot  information  in  data  element 

(2)  of  the  P 1 7 7  1 i st  entry  located  in  P596. 

P598:  Locate  the  end  time  slot  information  in  data  element  (2) 
of  the  P 1 7 7  list  entry  located  in  P573. 

P599:  Identify  the  time  slot  that  is  derived  by  subtracting  one 
time  slot  from  the  time  slot  information  in  P597.  To  do 
this  follow  the  Processing  Steps  (PS)  in  P226,  except: 

0  P226  should  be  P599. 

0  P212  should  be  P597. 


o 


P 22 7  should  be  P6D0. 
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P600:  Is  the  time  slot  derived  in  P599  equal  to  the  time  slot 
identified  in  P573?  Yes  =  P601 ;  No  =  P589 

P601:  Place  the  answer  'Yes'  in  data  element  (7b)  of  the  P518 
list  entry  for  this  iteration  of  FNl.22. 

P602:  NEXT  FNl.22;  end  of  FNl.22,  60  TO  FN1.23  (P603). 

FN1.23:  FOR  each  entry  on  the  P492  list,  i.e.,  for  each  task  in 
this  iteration  of  FNl: 

P603:  Identify  the  ID5  in  data  element  (1)  of  the  P492  list 
entry  for  this  iteration  of  FNl. 23. 

P604:  Identify  the  code  (1-3)  in  data  element  (2)  of  the  P492 

list  entry  for  this  iteration  of  FNl. 23.  Store  the  answer 
throughout  FNl. 23. 

P605:  Is  the  code  in  data  element  (9a)  of  the  P492  list  entry 
for  this  iteration  of  FNl. 23  a  'B1  (Beginning),  ' M ‘ 
(Marker)  or  'N C*  (No  Change)?  B  =  P655;  M  =  P655;  NC  = 
P606 

P606:  Determine  what  list  (P528  or  P529)  to  use  in  this 

iteration  of  FNl. 23.  Identify  the  code  in  data  element 
(9b)  of  the  P492  list  entry  for  this  iteration  of  FNl. 23. 
If  it  is  a  'a',  use  the  P528  list.  If  it  is  a  ’ b * ,  use 
the  P529  list.  Store  this  answer  throughout  FNl. 23. 

P607:  Locate  the  P528  list  (if  the  P606  code  was  'a')  or  P529 
list  (if  the  P606  code  was  ' b ‘ )  with  the  ID5  from  P603  as 
the  first  part  of  its  label.  Also,  if  the  code  in  P604 
was  a  '2'  (already  scheduled  task)  and  the  answer  in  P606 
was  ‘ b '  (locate  the  P529  list  also),  locate  the  P528  list 
corresponding  to  this  P529  list  and  compare  the  two  lists. 
If  the  entries  on  the  lists  are  exactly  the  same,  GO  TO 
P614;  otherwise  continue. 

P608:  Identify  the  P 1 7 7  list  entry  group  number  in  part  (2)  of 

the  label  of  the  P528/P529  list  located  in  P607. 

P6U9:  Locate  the  P349  list  for  the  P177  list  entry  group  number 
located  in  P608.  Also  locate  the  P518  list  entry  with  the 
P177  list  entry  group  number  from  P608  in  data  element 
(1). 

P6I0:  Add  an  entry  to  the  P516  list.  This  entry  consists  of  the 
3  parts  of  the  label  of  the  P528/P529  list  located  in 
P607,  i.e.,  the  105  from  P603,  the  P177  list  entry  group 
number  from  P608  and  the  code  'a'  (P528  list)  or  the  code 
' b*  (P529  list). 
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P611:  Add  '1'  to  the  data  element  (2d)  counter  at  the  top  of  the 
P516  list.  Also  add  '1'  to  the  data  element  (2a),  (2b) 
or  (2c)  counters,  depending  on  whether  the  P604  was  a 
•1' ,  '2'  or  '3'  . 

P612:  Add  the  value  in  data  element  (6)  (incorrect  time  use)  at 
the  top  of  the  P528/P529  list  from  P607  to  the  data 
element  (4)  counter  at  the  top  of  the  P516  list.  Also  add 
the  value  in  data  elements  (5a)  through  (5j)  (numbers  of 
various  types  of  tasks  that  will  need  to  be  rescheduled) 
at  the  top  of  the  P528/P529  list  from  P607  to  the  data 
element  (7a)  through  (7j)  counters  at  the  top  of  the  P516 
list. 

P613:  Locate  the  entry  on  the  P415  list  with  the  P 1 7 7  list  entry 
group  number  from  P608  in  data  element  (1). 

P614:  Identify  the  monthly  schedule  identifier  (ID27)  in  data 
element  (2)  of  the  P415  list  located  in  P613. 

P615:  Identify  the  1027  in  data  element  (3)  of  the  P415  list 
located  in  P6I3. 

P616:  Is  the  pair  of  1027s  identified  in  P614  and  P615  already 
on  the  P515  list?  Yes  =  P619;  No  =  P617 

P617:  Enter  the  pair  of  1027s  from  P614  and  P615  onto  the  P515 
list. 

P618:  Add  '1'  to  the  counter  in  data  element  (1)  at  the  top  of 
the  P516  list. 

P619:  Add  1 1 ‘  to  data  element  (3d)  counter  on  the  P518  list 

entry  located  in  P609.  Also  add  '1‘  to  the  data  element 
(3a),  (3b)  or  (3c)  counters,  depending  on  the  P604  code 
(1-3). 

P620:  Identic  the  value  in  data  element  (2)  (time  slots 

tentatively  scheduled)  at  the  top  of  the  P528/P529  list 
located  in  P607. 

P621:  Add  the  value  from  P620  to  data  element  (4d)  counter  on 
the  P513  list  entry  located  in  P609.  Also  add  the  value 
from  P62U  to  the  (4a),  (4b)  or  (4c)  counters,  depending 
on  the  P604  code. 

P622:  Locate  the  first  entry  on  the  P528/P529  1  i s t  from  P607. 

P623:  Identify  the  value  in  data  element  (1)  (P349  list  entry 

number)  of  the  P528/P529  list  entry  located  in  P622.  Is 
this  value  a  '1'?  Yes  { i . e . ,  the  scheduling  option  for 
the  task  in  this  iteration  of  FNl.23  begins  on  the  first 


STEP  F4A-3 


time  slot  of  the  P 1 7 7  list  entry  group  to  which  the 
scheduling  option  belongs)  =  P624;  No  =  P625 

P624:  Fill  in  data  element  (5)  of  the  P518  list  entry  located  in 
P609  with  the  answer  'Yes1. 

P625:  Locate  the  last  entry  on  the  P528/P529  list  from  P607. 

P626:  Identify  the  value  in  data  element  (1)  of  the  P528/P529 
list  entry  located  in  P625. 

P627:  Identify  the  value  in  data  element  (6)  of  the  P518  list 
entry  from  P609. 

P6 23:  Is  the  value  identified  in  P626  greater  than  the  value 
identified  in  P627?  Yes  =  P629;  No  =  P630 

P629:  Replace  the  value  in  data  element  (6)  of  the  P518  list 
entry  from  P609  with  the  value  identified  in  P626. 

FN 1.23.1:  FOR  each  entry  on  the  P528/P529  list  located  in  P607: 

P630:  Locate  the  value  in  data  element  (1)  (sequential  time  slot 
number)  on  the  P528/P529  list  entry  for  this  iteration  of 
FNl.23.1. 

P631:  locate  the  entry  on  the  P349  list  located  in  P609  that  has 
the  same  value  in  data  element  (1)  as  the  value  identified 
in  P630 . 

P632:  Place  a  flag  of  'S'  (indicating  that  the  time  slot  is 
tentatively  scheduled)  in  data  element  (7)  on  the  P349 
list  entry  located  in  P631. 

P633 :  NEXT  FNl.23.1;  end  of  FNl.23.1,  60  TO  P786. 

P634:  Is  the  flag  in  P491  an  'A'  or  a  ' B ' ?  A  =  P858  (next 
FnI.23);  B  =  P635 

P638:  Is  the  value  in  the  data  element  (3b)  counter  at  the  top 
of  the  P516  list  greater  than  'O'?  Yes  (i.e.,  it  was  not 
possible  to  schedule  one  of  the  'already  scheduled'  tasks 
using  this  combination  of  task  scheduling  options; 
therefore,  this  is  not  an  acceptable  scheduling  option)  = 
P637;  No  =  P636 

P636:  Is  the  value  in  the  data  element  (3a)  counter  at  the  top 
of  the  P516  list  greater  than  the  value  in  the  data 
element  (3a)  counter  at  the  top  of  the  P517  list?  Yes 
(i.e.,  even  though  this  combination  of  task  scheduling 
options  has  not  been  completed,  it  is  already  known  that 
more  'currently  being  scheduled'  tasks  will  not  be 
scheduled  with  this  combination  of  task  scheduling  options 
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than  with  the  current  best  scheduling  option  identified  so 
far;  therefore,  this  scheduling  option  is  abandoned)  = 
P637;  No  *  P858  (next  FN1.23) 

P637:  Erase  all  of  the  values  in  the  current  P516  list  (i.e., 
the  current  combination  of  task  scheduling  options), 
including  the  values  in  the  data  elements  at  the  top  of 
the  list.  However,  keep  the  blank  format  for  the  P516 
list.  Also  erase  the  value  in  data  element  (7)  for  al 1 
entries  on  all  P349  lists.  Also  erase  the  values  for  data 
elements  (3)  through  (7)  on  al 1  entries  on  the  P516 
list. 

P638:  Identify  the  value  in  data  element  (6)  (number  of  P492 
list  entries)  on  the  last  entry  on  the  P492  list. 

P639:  Store  a  counter,  called  the  P639  counter,  with  the  value 
from  P638. 

P640:  Locate  the  P492  list  entry  with  the  value  in  data  element 
(6)  equal  to  the  value  in  the  P639  counter. 

P641:  Is  the  answer  in  data  element  (10)  of  the  P492  list  entry 
located  in  P640  a  'Yes'  or  'No'?  Yes  (i.e.,  there  is  only 
one  scheduling  option  for  the  task  in  this  iteration  of 
FN1.23;  therefore,  do  not  reset  the  P 492  list  entries)  = 
P644;  No  =  P642 

P642;  Is  the  P639  counter  equal  to  the  value  from  P638?  Yes  ( 
i.e.,  the  P492  list  entry  located  in  P640  is  the  last 
entry  on  the  P492  list)  =  P 643 ;  No  =  P646 

P643:  Reset  the  value  in  the  P492  list  entry  from  P640:  Data 
elements  (1),  (2),  (4),  (6),  and  (10)  remain  unchanged. 

Set  the  flag  in  data  element  (3)  of  the  P492  list  entry 
located  in  P492  to  be  a  *  1 1 .  Set  the  counter  in  data 
elements  (5)  and  (7)  (point  the  P476  list  and  the  P361 
list  where  the  program  logic  left  off  in  the  last  search 
for  scheduling  options)  to  be  a  ’1’.  Set  data  element  (8) 
(whether  a  search  for  scheduling  options  for  this  task  has 
reached  an  end)  to  be  'No'.  Set  data  element  (9a)  to  be 
' B ‘  (i.e.,  start  next  search  for  scheduling  options  from 
the  beginning).  Also  identify  the  P529  list  with  the  ID5 
that  is  data  element  (1)  of  the  P492  list  entry  from  P640 
in  part  (1)  of  its  label.  Erase  this  P529  list.  Also 
identify  the  P526  list  with  the  ID5  that  is  data  element 
(1)  of  the  P492  list  entry  from  P640  in  part  (1)  of  its 
label  and  the  code  ' 5 *  (currently  being  formed)  as  part 
(3)  of  its  label.  Erase  this  P526  list. 

P644:  Subtract  ’ 1 '  from  the  Pb39  counter. 


P64d :  GU  TO  P6-0. 
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P646:  Is  the  P639  counter  equal  to  'O'?  Yes  =  FNl.23  (i.e., 

begin  the  FNl.23  iterations  over  again  starting  with  the 
first  task  on  the  P492  list);  No  =  P647 

P647 :  Is  there  a  P651  flag?  Yes  =  P653;  No  ■  P648 

P648:  Is  the  answer  in  data  element  (8)  (whether  the  program 

reached  an  end  for  search  for  scheduling  options  for  this 
task)  in  the  P492  list  entry  located  in  P640  a  'Yes'  or  a 
'No'?  Yes  =  P649;  No  =  P650 

P649:  Is  the  value  in  the  P639  counter  a  '1'?  Yes  (i.e.,  this 
is  the  first  entry  on  the  P492  list  and  the  program  has 
reached  an  end  in  the  search  for  scheduling  options  for 
the  task  on  this  P492  list  entry;  therefore,  the  search 
for  scheduling  options  is  completed)  =  P902;  No  =  P643 

P650:  Reset  the  values  in  the  P 492  list  entry  from  P640:  All 
data  elements  except  data  elements  (7)  and  (9)  remain 
unchanged.  Add  '1'  to  the  value  in  the  data  element  (7) 
counter  (point  on  the  P361  list  where  the  program  logic 
left  off  at  the  end  of  the  last  search  for  scheduling 
options).  Change  the  value  in  data  element  (9a)  to  read 
1 M '  (start  next  search  for  scheduling  options  from  the 
data  element  (7)  Marker).  Also  identify  the  P529  list 
with  the  ID5  that  is  data  element  (1)  of  the  P492  list 
entry  from  P640  in  part  (1)  of  its  label.  Erase  this  P549 
list.  Also  identify  the  P526  list  with  the  ID5  that  is 
data  element  (1)  of  the  P492  list  entry  from  P640  in  part 
(1)  of  its  label  and  code  ' b ’  as  part  (3)  of  its  label. 
Erase  this  P526  list. 

P651:  Set  a  flag,  called  the  P651  flag.  This  flag  indicates 
that  one  task  has  been  found  at  which  the  search  for 
scheduling  options  will  begin  at  the  point  after  the 
previous  search,  i.e.,  from  the  marker.  Therefore,  all 
tasks  higher  on  the  P492  list  than  the  task  in  the  P 492 
list  entry  corresponding  to  the  current  value  of  the  P639 
counter  will  remain  unchanged. 

P652:  GO  TO  P644. 

P653:  Reset  the  values  in  the  P492  list  entry  from  P640:  All 
data  elements  except  data  elements  (9a)  and  (9b)  remain 
unchanged.  Change  the  code  in  data  element  (9a)  to  be 
'NC'  (no  change  from  the  previous  scheduling  option). 

Fill  data  element  (9b)  with  the  code  ' b '  (use  the  P29  list 
for  the  task  scheduling  option  for  the  task  in  the  P492 
list  entry  correspond ing  to  the  current  value  in  the  P639 
counter ) . 
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P654:  GO  TO  P644. 

P655:  (From  P605):  Identify  the  entry  on  the  R2  list  from  PI 
that  contains  the  ID5  identified  in  P603. 

P656:  Identify  the  value  in  data  element  (11)  (task  performer 
group)  of  the  R2  list  entry  from  P655. 

P657:  Locate  the  P476  list  with  the  value  identified  in  P656  as 
its  label. 

P658:  Identify  the  value  in  data  element  (5)  (point  on  the  P476 
list  at  which  this  search  for  scheduling  options  should 
begin)  of  the  P492  list  entry  for  this  iteration  of 
FN1.23. 

P659:  Identify  the  value  in  data  element  (7)  (point  on  the  P 361 
list  at  which  this  search  for  scheduling  options  should 
begin) . 

FNl.23.2:  FOR  each  entry  on  the  P476  list  located  in  P657 

beginning  with  the  P476  list  entry  that  has  the  value  from 
P658  in  data  element  (7)  of  the  entry  (i.e.,  the  data 
element  containing  the  sequential  count  of  P476  list 
entries) : 

P660:  Identify  the  value  in  data  element  (6)  (P177  list  entry 

group  number)  of  the  P476  list  entry  for  this  iteration  of 
FNl.23.2. 

P661:  Locate  the  P361  list  with  the  label  consisting  of  the 
value  from  P660  (part  (1))  and  the  ID5  from  P603  (part 
(2)). 

P662:  Is  there  a  value  (answers  of  'Yes'  or  'No')  in  data 

element  (5)  (whether  it  is  possible  to  use  the  scheduling 
option  in  this  entry  of  the  P361  list)  of  the  data 
elements  at  the  top  of  the  P361  list  entry  located  in 
P661?  Yes  =  P663;  No  =  P664 

P663:  Is  the  answer  in  data  element  (5)  of  the  data  elements  at 
the  top  of  the  P361  list  entry  located  in  P661  a  'Yes*  or 
a  'No'?  Yes  =  P673;  No  =  P676 

P664:  Identify  the  value  in  data  element  (2)  (numbc.  of 

restricted  time  slots)  at  the  top  of  the  P361  list  from 
P661. 

P665:  Identify  the  value  in  data  element  (3)  (number  of  time 
slots  required  to  schedule  the  task)  at  the  top  of  the 
P361  list  from  P661. 
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P666:  Identify  the  value  in  data  element  (4)  (number  of  time 

slots  on  the  P361  list)  (i.e.,  time  slots  in  the  P177  list 
entry  group  represented  by  this  list)  at  the  top  of  the 
P361  list  from  P661. 

P667:  Derive  the  sum  that  is  equal  to  the  value  from  P664  plus 
the  value  from  P665.  Is  this  value  greater  than  the  value 
in  P666?  Yes  (i.e.,  there  are  not  enough  time  slots  on 
this  P36I  list  to  schedule  the  task  in  this  iteration  of 
FNl.23)  =  P668;  No  =  P670 

P668:  Fill  data  element  (5)  (whether  it  is  possible  to  schedule 
the  task  with  this  scheduling  option)  at  the  top  of  the 
P36I  list  located  in  P66I  with  the  answer  'No1. 

P669:  GO  TO  P676. 

P670:  Identify  the  value  in  data  element  (5)  (number  of  time 

slots  not  available  for  scheduling)  of  the  P476  list  entry 
for  this  iteration  of  FNl.23. 2. 

P671:  Derive  the  sum  of  the  value  from  P665  and  the  value  from 
P670.  Is  this  value  greater  than  the  value  in  P666?  Yes 
=  P668;  No  =  P672 

P672:  Fill  data  element  (5)  at  the  top  of  the  P361  list  located 
in  P661  with  the  answer  'Yes'. 

P673:  Is  the  value  identified  in  P659  (i.e.,  the  value  in  the 
counter  in  data  element  (7)  (point  on  the  P361  list  at 
which  this  search  for  scheduling  options  should  begin)  of 
the  P492  list  entry  for  this  iteration  of  FNl.23)  greater 
than  the  value  from  P666  (i.e.,  the  number  of  time  slots 
on  this  P361  list)?  Yes  (i.e.,  in  the  last  search  the 
program  reached  the  last  entry  on  the  P361  list  identified 
in  P661  and,  therefore,  when  the  P492  list  entry  values 
were  reset  in  P650,  the  marker  was  set  beyond  the  end  of 
this  P361  list)  =  P676;  No  =  P674 

P674:  Derive  the  value  that  is  equal  to  the  value  from  P666 

(total  time  slots  on  this  P361  list)  minus  the  value  from 
P659  (the  point  on  the  P361  list  where  the  program  will 
begin  its  search  for  scheduling  options)  plus  '1*.  This 
value  is  the  number  of  time  slots  left  on  the  P361  list  at 
this  point  in  the  scheduling  of  options. 

P675:  Is  the  value  from  P665  (time  slots  required  to  schedule 
this  task)  greater  than  the  value  derived  in  P674?  Yes  = 
P676;  No  =  P696 

P676:  Erase  the  current  values  in  the  P529  list  (if  any).  Do 
not  erase  the  P529  list  format,  however.  Also  erase  the 
P526  list  (if  any)  with  the  ID5  from  P603  as  part  (1)  of 
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its  label  and  the  code  1 b '  (currently  being  formed)  in 
part  (3)  of  its  label. 

P677:  Set  the  value  in  the  P520  through  P525  counters  and  the 
P527  counter  to  be  'O' . 

P678:  Identify  the  value  in  data  element  (4)  (number  of  entries 
on  the  P476  list)  of  the  P492  list  entry  for  this 
iteration  of  FN1.23. 

P679:  Is  the  value  from  P678  equal  to  the  value  from  P658  (point 
on  the  P476  list  at  which  this  search  for  scheduling 
options  is  now  located)?  Yes  (i.e.,  the  search  for 
scheduling  options  has  reached  the  end  of  the  P476  list 
for  the  current  flag  in  data  element  (3)  of  the  P492  list 
entry  for  this  iteration  of  FN1.23)  =  P683;  No  =  P680 

P680:  Add  1 1'  to  the  value  in  data  element  (5)  (point  on  the 

P476  list  where  this  program  search  for  scheduling  options 
is  located)  of  the  P492  list  entry  for  this  iteration  of 
FN1.23. 

P681:  Set  the  value  in  data  element  (7)  (point  on  the  P361  list 
where  the  search  for  scheduling  options  is  located)  of  the 
P492  list  entry  for  this  iteration  of  FNl.23  to  be  '1'. 

P682:  60  TO  P857  (next  FNl.23. 2). 

P683:  Is  the  code  in  P604  a  '1'  (currently  being  scheduled 
task)?  Yes  =  P684;  No  =  P687 

P684:  Is  the  flag  in  data  element  (3)  of  the  P492  list  entry  for 
this  iteration  of  FNl.23  equal  to  'll'?  Yes  =  P693;  No  = 
P685 

P685:  Add  ' 1 '  to  the  flag  in  data  element  (3)  of  the  P492  list 
entry  for  this  iteration  of  FNl.23. 

P686:  Set  the  value  in  data  elements  (5)  and  (7)  on  the  P492 

list  entry  for  this  iteration  of  FNl.23  to  be  '1'.  GO  TO 
P658. 

P687:  Is  the  flag  in  data  element  (3)  of  the  P492  list  entry  for 
this  iteration  of  FNl.23  equal  to  '3'?  Yes  =  P688;  No  = 
P685. 

P688:  Is  the  code  (1-3)  identified  in  P604  a  '2'  or  a  '3'?  2  = 

P689;  3  =  P691 

P689:  Add  ‘1’  to  data  elements  (3b)  and  (3d)  at  the  top  of  the 
PS16  list. 


P690:  GO  TO  P604. 
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P691:  Add  *1*  to  data  elements  (3c)  and  (3d)  at  the  top  of  the 
P516  list. 

P692:  GO  TO  P694. 

P693:  Add  '1*  to  data  elements  (3a)  and  (3d)  at  the  top  of  the 
P516  list. 

P694:  Place  the  answer  'Yes'  in  data  element  (8)  (whether  this 

task  has  reached  an  end  to  scheduling  options)  of  the  P492 
list  entry  for  this  iteration  of  FNl.23. 

P695 .  GO  TO  P634. 

P696:  Locate  the  P349  list  with  the  value  from  P660  (the  P177 
list  entry  group  number)  as  its  label. 

P697:  Locate  the  P455  list  with  the  value  from  P660  as  the  first 
part  of  its  label . 

P698:  Locate  the  P518  list  entry  with  the  value  from  P660  as  its 
data  element  (1). 

P699:  Obtain  the  answer  (Yes/No)  in  data  element  (4)  (whether 
this  scheduling  option  is  one  of  the  1027s  used  for  the 
'already  scheduled'  tasks)  of  the  P476  list  entry  for  this 
iteration  of  FNl.23. 2. 

P700:  Obtain  the  value  in  data  element  (7)  (identifying  the 
entry  on  the  P476  list)  of  the  P476  list  entry  for  this 
iteration  of  FNl.23. 2. 

P701:  Begin  to  generate  a  P529  list  for  the  task  in  this 

iteration  of  FNl.23.  (Erase  any  existing  P529  list  for 
this  task;  erase  any  1023  stored  in  P526;  set  the  P520 
through  P525  and  P527  counters  at  ’O'.)  Fill  in  part  (1) 
of  the  label  of  the  new  P529  list  with  the  ID5  from 
P603.  Fill  in  part  (2)  with  the  P177  list  entry  group 
number  from  P660.  Fill  in  part  (3)  with  the  code  'b1. 

Fill  in  the  following  data  elements  at  the  top  of  the 
P529  list:  Data  element  (1)  is  the  code  from  P604.  Fill 
in  all  counters  from  P525  that  are  in  data  elements  (2) 
through  (6)  at  the  top  of  the  P529  list  with  a  'O’.  The 
answer  in  data  element  (7)  is  the  answer  obtained  from 
P699.  Data  elements  (9),  (10),  (11)  and  (12)  should  be 
the  value  in  data  elements  (7),  (6),  (4b)  and  (9)  of  the 
R2  list  entry  from  P655  .  Fill  in  data  element  (13)  of  trie 
data  elements  at  the  top  of  the  P529  list  with  the  ID23  in 
data  element  (1)  on  the  R2  list  entry  from  P655,  if  there 
is  an  entry  in  data  element  (1)  (otherwise,  leave  data 
element  (13)  on  the  top  of  the  P529  list  blank).  Also 
generate  a  new  P 526  list  for  the  task  in  this  iteration  of 
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FNl.23.  (Erase  the  existing  P526  lists  (if  there  is  one) 
for  this  task  that  have  the  code  of  ' b 1  in  part  (3)  of  its 
label.)  Fill  in  the  label  for  this  new  P526  list  with  the 
same  label  as  the  P529  list  g  in  this  substep. 

P702:  Identify  the  employee  identifier  (ID4)  in  data  element  (1) 
of  the  P476  list  entry  for  this  iteration  of  FNl.23.2. 
Place  this  in  data  element  (8)  on  the  newly  generated  P529 
list  for  this  iteration  of  FNl.23  (as  started  in  P701). 

P703:  Identify  the  first  monthly  schedule  identifier  (ID27)  in 

data  element  (2)  of  the  P476  list  entry  for  this  iteration 
of  FNl.23.2. 

P704:  Identify  the  second  1027  in  data  element  (3)  of  the  P476 
list  entry  for  this  iteration  of  FNl.23.2. 

P705:  Identify  the  value  in  data  element  (3)  (time  slots 

required  for  the  task)  at  the  top  of  the  P361  list  from 
P661 . 

P706:  Identify  t;e  value  in  data  element  (4)  (time  slots  on  the 
P361  list)  at  the  top  of  the  P361  list  from  P661. 

P 70 7 :  Locate  the  entry  on  the  P361  list  located  in  P661  with  the 
value  from  P659  in  data  element  (1). 

P708:  Identify  and  store  the  month  (1-12)  that  is  data  element 
(3)  of  the  P361  list  entry  located  in  P705. 

FNl.23.2.1:  FOR  each  entry  on  the  P361  list  located  in  P661 

starting  with  the  P 361  list  entry  that  has  the  value  from 
P659  in  data  element  (1)  (i.e.,  the  value  in  the  data 
element  (4)  counter  on  the  P 492  list  entry  for  this 
iteration  of  FNl.23): 

P 709 :  Identify  the  value  that  is  in  data  element  (1)  (sequential 
time  slot  counter)  of  the  P 361  list  entry  for  this 
iteration  of  FNl.23. 2.1. 

P710:  Derive  the  value  that  is  equal  to  the  value  identified  in 
P706  (time  slots  in  the  P361  list)  minus  the  value 
identified  in  P709,  plus  This  value  is  equal  to  the 

maximum  number  of  entries  (time  slots)  left  on  the  P361 
list  for  this  iteration  of  FNl.23.2  starting  with,  and 
including,  the  entry  for  this  iteration  of  FNl.23. 2.1. 

P71i:  Derive  the  value  that  is  equal  to  the  value  currently  in 
the  P520  counter  (time  slots  tentatively  scheduled)  minus 
the  value  currently  in  the  P522  counter  (number  of 
interruptions) .  This  value  is  equal  to  the  number  of  time 
slots  that  still  need  to  be  scheduled  for  the  task  in  this 
iteration  of  FNl.23. 
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P712:  Is  the  value  identified  in  P711  greater  than  the  value 
derived  in  P 710?  Yes  =  P676 ;  No  =  P713 

P713:  Identify  the  answer  (Yes/No)  in  data  element  (7)  (whether 
this  time  slot  is  restricted)  of  the  P361  list  entry  for 
this  iteration  of  FNl. 23. 2.1.  Is  the  answer  a  'Yes'  or  a 
'No'?  Yes  =  P714;  No  =  P719 

P714:  Does  the  P520  counter  (time  slots  tentatively  scheduled) 
contain  a  value  greater  than  ‘O'?  Yes  (i.e.,  the  time 
slot  in  this  iteration  of  FNl. 23. 2.1  is  an  interruption  of 
the  scheduling  of  the  task  in  this  iteration  of  FNl. 23)  = 
P715;  No  (i.e.,  the  beginning  of  the  tentative  scheduling 
of  this  task  has  not  yet  been  reached)  =  P717 

P715:  Erase  the  P529  list  for  this  iteration  of  FNl. 23. 2  (as 
started  in  P 701 ) .  Also  locate  the  P526  list  with  the 
requirement  application  identifier  (ID5)  from  P603  as  the 
first  part  of  its  label  and  the  code  1 b 1  (currently  being 
formed)  as  the  third  part  of  its  label.  Erase  this  P526 
list. 

P716:  Set  the  P520  through  P525  and  P527  counters  to  be  'O'. 

P717:  Place  the  value  identified  in  P709  in  data  element  (7)  on 
the  P492  list  entry  for  this  iteration  of  FNl. 23. 

P718:  GO  TO  P782  (next  FNl. 23. 2.1). 

P719:  Locate  the  entry  on  the  P349  list  located  in  P696  that  has 
the  value  identified  in  P709  in  data  element  (1)  of  the 
P349  list  entry. 

P720:  Identify  the  answer  (blank,  'S',  'I')  in  data  element  (7) 
(whether  this  time  slot  is  tentatively  scheduled)  on  the 
P349  list  entry  located  in  P719.  Is  this  answer  a  blank 
(i.e.,  not  tentatively  scheduled),  an  'S'  or  an  'I'? 
blank  =  P721;  S  =  P714;  I  =  P721 

P721:  Locate  the  entry  (time  slot)  on  the  P455  list  located  in 
P697  with  the  value  from  P709  in  its  data  element  (1). 

P722:  Is  there  a  code  ( ' B '  or  * T ' )  (i.e.,  an  indication  that 
this  time  slot  is  not  available  for  scheduling)  in  data 
element  (5)  on  the  P455  list  entry  located  in  P721?  Yes 
with  a  code  of  ' B *  (i.e.,  this  time  slot  is  not  available 
for  scheduling  because  of  a  break  in  the  employee's  time 
who  will  perform  the  tasks  on  the  DS27  data  corresponding 
to  this  P455  list  entry,  e.g.,  a  lunch  break)  =  P723;  Yes 
with  a  code  of  ' T '  (i.e.,  this  time  slot  is  not  available 
for  scheduling  because  other  tasks  have  already  been 
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scheduled  in  this  time  slot  and  these  are  tasks  that 
cannot  be  rescheduled)  =  P714;  No  =  P732 

P723:  Identify  the  flag  in  data  element  (3)  on  the  P492  list 
entry  for  this  iteration  of  FNl.23.  Is  this  flag  a  '1' 
(i.e.,  is  this  search  for  scheduling  options  using  the 
first  (most  rigid)  criteria  for  selection  of  scheduling 
options)?  Yes  =  P 71 4 ;  No  =  P724 

P724:  Does  the  P520  counter  (time  slots  tentatively  scheduled) 
contain  a  value  greater  than  'O'?  Yes  =  P725;  No  =  P 71 5 

P725:  Does  the  P521  counter  (time  slots  tentatively  scheduled 

since  the  last  interruption)  contain  the  value  'O';  '1'  or 
'2';  or  'greater  than  two'?  0  (i.e.,  this  interruption  in 
the  scheduling  of  the  task  is  a  continuation  of  an 
interruption  that  has  already  started)  =  P729;  1  or  2 
(i.e.,  there  are  insufficient  numbers  of  time  slots 
scheduled  for  this  task  before  the  task  has  an 
interruption  to  justify  this  scheduling  option)  =  P715; 
greater  than  2  =  P726 

P726:  Derive  the  value  equal  to  the  value  from  P705  (time  slots 
required  for  this  task)  plus  the  value  from  the  P522 
counter  (number  of  interruptions). 

P727:  Derive  the  value  that  is  equal  to  the  value  derived  in 

P726  minus  the  value  in  the  P520  counter  (number  of  time 
slots  tentatively  scheduled).  Is  this  value  greater  than 
'2'?  Yes  =  P728;  No  (i.e.,  there  are  insufficient  numbers 
of  time  slots  left  to  schedule  in  this  task  to  justify  an 
interruption  in  the  scheduling  of  the  task  at  this  point; 
therefore,  this  scheduling  option  is  precluded)  =  P715 

P728:  Add  '1'  to  the  P522  counter  (number  of  interruptions) . 

P729:  Add  '1'  to  the  P524  counter  and  add  '1'  to  the  P523 

counter  (number  of  time  slots  that  are  interruptions). 

Set  the  value  in  the  P521  counter  to  be  'O'. 

P730:  Is  the  value  in  the  P523  counter  (number  of  time  slots 

that  are  interruptions)  greater  than  one  half  of  the  value 
from  P705  (time  slots  required  to  schedule  this  task)? 

Yes  (i.e.,  there  are  too  many  interruptions  on  the 
scheduling  of  this  task  to  justify  this  scheduling  option) 
=  P715 ;  No  =  P731 

P731:  If  the  value  in  the  P524  counter  is  greater  than  '3',  then 
GO  TO  P715.  If  not,  enter  the  value  from  P709  (the  P361 
list  entry  number)  onto  a  list,  called  the  P731  list. 

This  list  is  maintained  in  order  that  the  interruptions  in 
the  scheduling  of  this  task  may  be  entered  onto  the  P349 
list  as  not  being  available  for  scheduling;  this  is  done 
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in  order  to  keep  these  interruptions  from  being  scheduled 
by  other  tasks  in  this  iteration  of  FNl,  which  is  not 
desirable  because  it  would  mean  interrupting  one  task  to 
perform  another.  Then,  if  the  answer  in  P724  was  'Yes', 

60  TO  P782  (next  FN 1.23.2.1).  If  the  answer  was  'No',  60 
TO  P717 . 

P732:  Identify  the  value  in  data  element  (3)  (month)  of  the  P361 
list  entry  for  this  iteration  of  FNl. 23. 2.1.  Is  this 
value  the  same  as  the  value  from  P708?  Yes  =  P733;  No  = 
P734 

P 733 :  Locate  the  DS27  data  correspond ing  to  the  ID27  identified 
in  P703.  60  TO  P735. 

P734:  Locate  the  DS27  data  corresponding  to  the  ID27  identified 
in  P704. 

P735:  Identify  the  value  in  data  element  (4)  (day  of  the  month) 
of  the  P361  list  entry  for  this  iteration  of  FNl. 23. 2.1. 

P736:  Identify  the  value  in  data  element  (5)  (time  slot  number) 
of  the  P361  list  entry  for  this  iteration  of  FNl. 23. 2.1. 

P 737 :  Locate  the  time  slot  on  the  DS27  data  for  this  iteration 
of  FNl. 23. 2.1  (i.e.,  the  DS27  data  from  P732  or  from  P734) 
that  is  for  the  day  of  the  month  with  the  value  from  P735 
and  the  time  slot  number  with  the  value  from  P736. 

P738:  Is  the  time  slot  located  in  P737  already  scheduled  with  a 
task?  (Note:  The  answer  is  shown  on  the  DS27  data.)  Yes 
=  P739;  No  =  P736 

P739:  Is  the  flag  in  data  element  (3)  of  the  P492  list  entry  for 
this  iteration  of  FNl. 23  greater  than  *3'?  Yes  (i.e.,  the 
program  has  reached  the  point  in  the  search  for  scheduling 
options  in  which  the  possibility  of  rescheduling  other 
tasks  will  be  considered  in  order  to  schedule  all 
'employee  transport'  tasks  for  the  same  employee  at 
approximately  the  same  time)  =  P 740 ;  No  =  P 71 4 

P740:  Identify  the  task  identifier  (ID23)  of  the  task  scheduled 
in  the  time  slot  identified  in  P737. 

P741:  Locate  the  P526  list  with  the  ID5  from  P603  as  the  first 
part  of  its  label  and  the  code  ' b '  (currently  being  formed 
list)  as  the  third  part  of  its  label. 


P742:  Is  the  task  identifier  (1023)  from  P740  on  the  P526  list 
located  in  P741?  Yes  (i.e.,  the  program  has  previously 
identified  time  slots  scheduled  for  this  task  as  subject 


STEP  F4A-3 


to  rescheduling,  if  the  tentative  scheduling  for  the  task 
in  this  iteration  of  FN1.23  is  selected)  =  P776;  No  =  P743 

P743:  Determine  whether  the  task  currently  scheduled  in  the  time 
slot  located  in  P737  has  any  standard  restrictions? 

(Note:  This  task  cannot  have  any  special  restrictions, 
because,  if  it  did,  it  would  have  been  eliminated  in  the 
P722  check).  Yes  =  P744;  No  =  P760  (Note:  The  answer  to 
this  question  and  the  following  questions  about  the  nature 
of  the  task  that  is  scheduled  in  the  time  slot  identified 
in  P 737  can  be  obtained  using  the  DS27  data  from 
P  732/P  734 . ) 

P744:  Is  the  flag  in  data  element  (3)  of  the  P492  list  entry  for 
this  iteration  of  FNl.23  greater  than  '6'?  Yes  =  P745  ;  No 
=  P  71 4 

P745:  Is  the  time  slot  identified  in  P737  scheduled  for  a  task 
that  was  initiated  based  on  a  requirement  or  based  on 
Reminder  Notice  type  suspense  data?  Reminder  Notice  = 
P746;  requirement  =  P748 

P746:  Add  to  the  P525d  counter. 

P747:  GO  TO  P769. 

P748:  Is  the  P737  time  slot  scheduled  with  a  task  that  is  dated 
(i.e.,  has  a  due  date)?  Yes  =  P749;  No  =  P755 

P749:  Is  the  flag  in  data  element  (3)  of  the  P492  list  entry  for 
this  iteration  of  FNl.23  greater  than  '9'?  Yes  =  P750;  No 
=  P714 

P750:  Is  the  P737  time  slot  scheduled  with  a  task  that  is 

mandatory  or  recommended?  man  =  P751;  recommended  =  P753 

P751:  Add  '1'  to  the  P525h  and  the  P525i  counters. 

P 75 2 :  GO  TO  P769. 

P753:  Add  '1'  to  the  P525 g  and  P525  i  counters. 

P754:  GO  TO  P769. 

P755:  Is  the  P737  time  slot  scheduled  with  a  task  that  is 

mandatory  or  recommended?  mandatory  =  P756;  recommended  = 
P  758 

P756:  Add  ’1'  to  the  P525f  counter. 

P757:  GO  TO  P769. 

P758:  Add  ' 1 1  to  the  P525e  counter. 
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P759:  60  TO  P769. 


P  760 : 

Is  the  P737  time  slot  scheduled  with  a  task  that  was 
initiated  based  on  a  requirement  or  on  a  Reminder  Notice 
type  suspense  data?  requirement  =  P763;  Reminder  Notice  = 
P761 

P  761 : 

Add  '1'  to  the  P525a  counter. 

P  762 : 

60  TO  P769. 

P763: 

Is  the  flag  in  data  element  (3)  of  the  P492 
this  iteration  of  FNl.23  greater  than  ' 4 *  ? 

=  P714 

list  entry  for 
Yes  =  P764;  No 

P764: 

Is  the  P737  time  slot  scheduled  with  a  task 
mandatory  or  recommended?  mandatory  =  P767 
P765 

that  is 
recommended  = 

P765: 

Add  *  1 1  to  the  P525b  counter. 

P  766 : 

60  TO  P769. 

P767: 

Is  the  flag  in  data  element  (3)  of  the  P492 
this  iteration  of  FNl.23  greater  than  '5'? 

-  P714 

list  entry  for 
Yes  =  P768;  No 

P768: 

Add  '1'  to  the  P525c  counter. 

P769: 

Locate  the  P526  list  with  the  ID5  from  P603  as  the  first 
part  of  its  label  and  the  code  1 b'  (currently  being 
formed)  as  the  third  part  of  its  label. 

P770: 

Place  the  task  identifier  (ID23)  identified 
the  P526  list  located  in  P769. 

in  P740  onto 

P771: 

Add  ’ 1 '  to  the  P525j  counter. 

P  772: 

Identify  the  preferred  time  use  code  (CT11) 
DS27  data  from  P732/P734  for  the  time  slot 
P737. 

given  on  the 
located  in 

P773: 

Is  the  time  use  code  (CT11)  identified  in  P 7 72  the  same  as 
the  time  use  code  in  data  element  (9)  on  the  P529  list  for 
this  iteration  of  FNl.23  (as  started  in  P701 ) ?  Yes  = 

P776;  No  =  P774 

P  7  74 : 

Is  the  flag  in  data  element  (3)  of  the  P492 
this  iteration  of  FNl.23  greater  than  '2'? 

list  entry  for 
Yes  (i.e.,  the 

program  is  at  the  point  of  searching  for  scheduling 
options  for  the  task  in  this  iteration  of  FNl.23  that  it 
will  disregard  preferred  time  use  codes  as  the  criteria 
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for  not  scheduling  a  task  in  a  time  slot)  =  P775;  No  = 

P  714 

P775:  Add  *1*  to  the  P527  counter. 

P776:  Is  the  value  in  the  P520  counter  (time  slots  tentatively 
scheduled)  equal  to  'O'?  Yes  =  P 77 7 ;  No  =  P778 

P777:  Place  the  value  identified  in  P709  into  data  element  (7) 
(point  on  the  P361  list)  of  the  P 492  list  entry  for  this 
iteration  of  FN 1.23. 

P778:  Add  *1'  to  the  P520  counter  (time  slots  tentatively 

scheduled)  and  the  P521  counter  (time  slots  tentatively 
scheduled  since  the  last  interruption). 

P779:  Set  the  P524  counter  (number  of  time  slots  that  are 
interruptions  since  the  beginning  of  the  last 
interruption)  to  be  'O'. 

P780:  Add  an  entry  to  the  P529  list  generated  in  this  iteration 
of  FNl.23.2  (as  started  in  P701).  Fill  in  data  element 
(1)  of  the  new  P529  list  entry  with  the  value  from  P709. 
Fill  in  data  element  (2)  (time  slot  information)  with  the 
1027  for  this  iteration  of  FNl.23.2.1  (from  P703/P704) 
(part  (1));  the  date  from  P73 5  (part  (2));  and,  the  time 
slot  number  from  P736  (part  (3)).  Fill  in  date  elements 
(3)  through  (7)  with  the  values  in  the  P520  through  P524 
counters.  Fill  in  data  element  (8)  with  th>'  answer  given 
in  P773. 

P781:  Derive  the  sum  that  is  equal  to  the  value  from  P705  (time 
slots  required  for  this  task)  plus  the  value  from  the  P522 
counter  (number  of  interruptions).  Is  this  value  equal  to 
the  value  in  the  P520  counter  (number  of  time  slots 
tentatively  scheduled)?  Yes  (i.e.,  a  tentative  task 
scheduling  option  has  been  identified  for  the  task  in  this 
iteration  of  FN1.23)  =  P783;  No  =  P782  (next  FN 1 . 23 .2.1) 

P782:  NEXT  FNl.23.2.1;  end  of  FNl.23.2.1,  GO  TO  P676. 

P783:  Complete  data  elements  (2)  through  (6)  at  the  newly 
generated  P529  list  for  this  iteration  of  FN 1 . 23  (as 
started  in  P701)  with  the  current  value  in  the  P520 
through  P525  and  P527  counters,  respectively. 

P784:  Set  the  value  in  the  P520  through  P525  and  P527  counters 
to  be  'O'. 


P 785 :  GO  TO  P607. 
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P786:  (From  P633):  Are  there  any  entries  on  the  P731  list  (list 
of  time  slot  numbers  for  interruptions)?  Yes  =  FN 1.23.2.2 
(P787 ) ;  No  =  P791 

FN1.23.2.2:  FOR  each  entry  on  the  P731  list: 

P 787 :  Locate  the  entry  on  the  P349  list  from  P696  that  contains 
the  value  of  the  entry  on  the  P731  list  for  this  iteration 
of  FNl.23.2.2  in  data  element  (1)  of  the  P349  list  entry. 

P788:  Enter  a  ' I  *  in  data  element  (7)  of  the  P349  list  entry 
located  in  P787. 

P789:  NEXT  FNl.23.2.2;  end  of  FNl.23.2.2,  GO  TO  P790. 

P790:  Erase  the  P 731  list. 

P791:  Is  the  value  in  data  element  (4d)  (number  of  time  slots 
tentatively  scheduled  for  a  given  P177  list  entry  group) 
in  the  P518  list  entry  located  in  P698  greater  than  '17'? 
Yes  (i.e.,  the  employee  for  which  the  'employee  transport' 
tasks  in  this  iteration  of  FNl  are  being  scheduled  has 
been  scheduled  to  participate  in  at  least  4  1/2  hours  of 
tasks;  therefore,  a  check  needs  to  be  made  to  determine  if 
there  are  many  breaks  in  the  tasks  tentatively  scheduled 
as  a  part  of  this  iteration  of  FNl  in  which  this  employee 
will  be  participating)  =  P792;  No  =  P810 

P792:  Is  the  answer  in  data  element  (7e)  (whether  extra 

interruptions  have  been  entered)  of  the  P518  entry  located 
in  P698  a  'Yes'  or  ’No’?  Yes  =  P81U;  No  =  P793 

P793:  Start  a  counter,  called  the  P 793  counter  with  the  value 
■O' . 

P794:  Start  a  counter,  called  the  P794  counter  with  the  value 
'O' . 


FNl .23. 2. 3:  FOR  each  entry  on  the  P349  located  in  P696: 

P795:  Identify  the  value  in  data  element  (7)  (whether 

tentatively  scheduled)  of  the  P349  list  entry  for  this 
iteration  of  FNl .23.2.3. 

P796:  Is  the  value  from  P796  a  'blank',  'S'  or  a  1 1 1 ?  Blank  = 
P 799;  S  =  P 797;  I  =  P807 

P797:  Add  ' 1  *  to  the  P 793  counter. 

P798:  GO  TO  P308  (next  FNl. 23. 2. 3). 

P 7 9 9 :  Is  the  P/93  counter  greater  than  '17'?  Yes  =  P802;  No  = 

P8U0 
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P800: 

P801: 

P802: 

P803: 
P804 : 

P805 : 


P806: 

P8U7: 

P808: 

P809: 

P81U : 

P  81 1 : 

P812 : 

P813: 

P814: 

P815: 

P  81 6 : 
P817: 


Set  the  P793  counter  to  be  'O'. 

GO  TO  P808  (next  FNl  .23.2.3) . 

Place  the  value  'I'  in  data  element  (7)  of  the  P349  list 
entry  for  this  iteration  of  FNl. 23. 2. 3. 

Add  '1'  to  the  P794  counter. 

Is  the  P794  counter  equal  to  ’2’?  Yes  =  P805;  No  =  P808 
(next  FNl. 23. 2. 3) 

Place  the  answer  'Yes’  in  data  element  (7e)  of  the  P518 
list  entry  from  P698  thus  indicating  that  extra  'I' 

( interruptions)  entries  have  already  been  put  onto  the 
P349  list  located  in  P696. 

GO  TO  P810 . 

Is  the  P793  counter  greater  than  '17‘?  Yes  =  P803;  No  = 
P800 

NEXT  FNl. 23. 2. 3;  end  of  FNl. 23. 2. 3,  GO  TO  P809. 


Is  the  P794  counter  greater  than  '17'?  Yes  (i.e.,  there 
was  not  sufficient  space  left  on  the  P349  list  to  enter 
extra  'I'  codes)  =  P805;  No  =  P810 


Identify  the  value  in  data  element  (4d)  (number  of  time 
slots  scheduled)  on  the  P518  entry  from  P698. 


Identify  the  answer  given  in  data  element  (7a)  (whether 
this  P177  list  entry  group  continues  immediately  after  a 
previous  group)  of  the  P518  list  entry  identified  in  P698. 

Is  the  answer  identified  in  P811  a  'Yes1  or  a  'No'?  Yes  = 
P813 ;  No  =  P840 


Is  the  answer  in  data  element  (7c)  (whether  extra 
interruptions  have  been  entered)  of  the  P518  list  entry 
located  in  P698  a  'Yes'  or  a  'No'?  Yes  =  P840;  No  =  P814 

Identify  the  value  in  data  element  (1)  of  the  P518  list 
entry  from  P698. 

Store  a  counter,  called  the  P815  counter,  with  the  value 
from  P814. 


Subtract  '1'  from  the  P815  counter. 

Is  there  a  P51S  list  entry  with  the  value  from  the  P815 
counter  in  data  element  (1)?  Yes  =  P818;  No  =  P816 
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P818:  Locate  the  P518  list  entry  with  the  value  from  the  P815 
counter  as  its  data  element  (1). 

P819:  Identify  the  value  in  data  element  (4d)  (number  of  time 
slots  scheduled)  on  the  P518  list  entry  located  in  P818. 

P820:  Derive  the  value  equal  to  the  value  from  P810  plus  the 
value  from  P819.  Is  this  value  equal  to  greater  than 
'17'?  Yes  =  P821 ;  No  =  P840 

P821:  Locate  the  P349  list  with  the  value  from  the  P815  counter 
as  its  label. 

P822:  Locate  the  value  in  data  element  (1)  of  the  last  entry  on 
the  P349  list  located  in  P821. 

P823:  Start  a  counter,  called  the  P823  counter,  with  the  value 
from  P822. 

P824:  Start  a  counter,  called  the  P824  counter,  with  the  value 
of  'O'  . 

P825:  Start  a  counter,  called  the  P825  counter,  with  the  value 
'O'  . 

P826:  Locate  the  P349  list  entry  with  a  value  in  data  element 
(1)  equal  to  the  value  in  the  P823  counter. 

P827:  Identify  the  value  in  data  element  (7)  of  the  P349  list 

entry  located  in  P826.  Is  this  value  a  'blank',  'S'  or  a 
T?  blank  =  P835;  S  =  P828;  I  =  P839 

P828:  Add  ' 1 '  to  the  P824  counter. 

P829:  Is  the  P823  counter  equal  to  '1'?  Yes  =  P830;  No  =  P833 

P830:  Is  the  P824  counter  greater  than  '17'?  Yes  =  P831 ;  No  = 
P840 

P831:  Place  the  answer  'Yes'  in  data  element  (7c)  of  the  P518 
list  entry  located  in  P698. 

P832 :  GO  TO  P840. 

P833:  Subtract  '1'  from  the  P823  counter. 

P834:  GO  TO  P826. 

P83t>:  Is  the  P824  counter  greater  than  '17'?  Yes  =  P836;  No  = 
P84U 


P836:  Place  the  value  'I*  in  data  element  (7)  of  the  P349  list 
entry  located  in  P826. 

P837:  Add  '1'  to  the  P825  counter. 

P838:  Is  the  P825  counter  equal  to  '2'?  Yes  =  P840;  No  =  P829 

P839:  Is  the  P824  counter  greater  than  ' 1 7 1 ?  Yes  =  P837;  No  = 
P840 

P840:  Is  the  answer  given  in  data  element  (7b)  (whether  this 

P177  list  entry  group  is  continued  immediately  after  its 
end  by  another  P177  list  entry  group)  of  the  P518  list 
entry  identified  in  P698  a  'Yes'  or  a  'No'?  Yes  =  P841; 
No  =  P856 

P841:  Is  the  answer  in  data  element  (7d)  (whether  extra 

interruptions  have  already  been  entered)  of  the  P518  list 
entry  located  in  P698  a  ‘Yes'  or  a  ‘No1?  Yes  =  P856;  No 
P842 

P842:  Start  a  counter,  called  the  P842  counter,  with  the  value 
of  'O'. 

FNl.23.2.4:  FOR  each  entry  on  the  P349  list  located  in  P696: 

P843:  Identify  the  value  in  data  element  (7)  (whether 

tentatively  already  scheduled)  of  the  P349  list  entry  for 
this  iteration  of  FNl.23.2.4. 

P844:  Is  the  value  from  P843  a  'blank',  'S'  or  a  'I'?  blank  = 
P847 ;  S  =  P845 ;  I  =  P853 

P845:  Add  'l1  to  the  P824  counter. 

P846 :  GO  TO  P854  (next  FNl.23.2.4). 

P847:  Is  the  P824  counter  greater  than  '17'?  Yes  =  P848;  No  = 
P856 

P848:  Place  the  value  'I'  in  data  element  (7)  of  the  P349  list 
entry  for  this  iteration  of  FNl.23.2.4. 

P849:  Add  *  1 '  to  the  P842  counter. 

P850:  Is  the  P842  counter  equal  to  '2'?  Yes  =  P851;  No  =  P854 
(next  FNl.23.2.4) 

P851:  Place  the  answer  'Yes'  in  data  element  (7d)  of  the  P518 
list  entry  from  P698. 
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P 85 3 :  Is  the  P824  counter  greater  than  '17'?  Yes  =  P849;  No  = 

P856 

P 854 :  NEXT  FNl.23.2.4;  end  of  FN1.23.2.4,  60  TO  P855. 

P855:  Is  the  P824  counter  greater  than  '17'?  Yes  =  P851;  No  = 
P634 

P856:  GO  TO  P634. 

P857:  NEXT  FN1.23.2;  end  of  FNl.23.2,  30  TO  P858. 

P858:  NEXT  FN1.23;  end  of  FN1.23,  GO  TO  P859. 

P859:  Is  the  value  in  data  element  (2a)  (number  of  currently 

being  scheduled  tasks  tentatively  scheduled  in  this 
combination  of  task  scheduling  options)  at  the  top  of  the 
P516  list  equal  to  'O’?  Yes  (i.e.,  this  is  not  an 
acceptable  scheduling  option  because  none  of  the  currently 
being  scheduled  tasks  were  tentatively  scheduled  in  this 
scheduling  option)  =  P637;  No  =  P860 

P860:  Start  a  counter,  called  the  P860  counter,  with  the  value 

'O'  . 

P861:  Start  a  counter,  called  the  P861  counter,  with  the  value 
'O'. 


FN1.24:  FOR  each  entry  on  the  P518  list: 

P862:  Is  the  answer  in  data  element  (5)  (whether  the  first  time 
slot  was  scheduled)  a  'Yes'  or  a  'No'?  Yes  =  P863;  No 
(i.e.,  the  combination  of  task  scheduling  options  shown  on 
the  current  P516  list  is  not  acceptable)  =  P637 

P863:  Identify  the  value  in  data  element  (4d)  (number  of  time 
slots  scheduled  in  this  task  scheduling  option)  of  the 
P5I8  list  entry  for  this  iteration  of  FN1.24. 

P864:  Identify  the  value  in  data  element  (6)  (latest  time  slot 

scheduled  in  this  task  scheduling  option)  of  the  P518  list 
entry  for  this  iteration  of  FN1.24. 

P865:  Add  the  value  from  P864  to  the  P860  counter. 

P866:  Is  the  value  from  P864  more  than  twice  the  value  from 

P863,  i.e.,  is  the  amount  of  calendar  time  to  schedule  the 
tasks  in  this  combination  of  task  scheduling  options, 
including  the  amount  of  time  between  the  tasks 
scheduled,  in  this  P177  list  entry  (as  portrayed  by  this 
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P518  list  entry)  greater  than  twice  the  amount  of  time 
scheduled  for  the  tasks?  (Note:  We  are  not  concerned 
here  with  the  total  calendar  time  for  al 1  P177  list 
entry  groups  (i.e.,  for  all  tasks  scheduled  in  this  FNl), 
because  each  P177  list  entry  group  begins  with  the  time 
slot  in  which  an  'already  scheduled'  task  was  originally 
scheduled  and  these  first  time  slots  on  the  P177  list 
entry  groups  remain  fixed  as  the  point  in  which  groups  of 
employee  transport  tasks  scheduled  for  the  employee  in 
this  FNl  will  begin.  (More  than  one  entry  on  the  P 177 
list  indicates  that  the  program  previously  it  was  not 
possible  to  schedule  one  or  more  of  the  employee  transport 
tasks  for  the  employee  in  this  iteration  of  FNl  at 
approximately  the  same  time  as  already  scheduled  employee 
transport  tasks  for  the  same  employee.)  The  program  logic 
has  endeavored  to  schedule  all  new  (currently  being 
scheduled)  and  future  employee  transport  tasks  for  the 
same  employee  at  approximately  the  same  time  (i.e.,  within 
the  same  9  hour  period  as  represented  by  a  P177  list  entry 
group).  If,  however,  the  combination  of  task  scheduling 
options  described  by  the  P518  list  entry  for  this 
iteration  of  FNl. 24  indicates  that  the  tasks  have  been 
spread  so  far  apart  that  the  time  between  tasks  scheduled 
is  greater  than  twice  the  time  for  scheduling  the  tasks, 
this  indicates  that  this  is  not  an  ideal  scheduling 
option.)  Yes  =  P867;  No  =  P870 

P867:  Add  '1'  to  the  P861  counter. 

P868:  Fill  in  data  element  (8)  on  the  P518  list  entry  for  this 
iteration  of  FNl. 24  with  a  'Yes'. 

P869:  60  TO  P871  (next  FNl. 24). 

P870:  Fill  in  data  element  (8)  on  the  P518  list  entry  for  this 
iteration  of  FNl. 24  with  a  'No'. 

P871:  NEXT  FNl. 24,  end  of  FNl. 24,  GO  TO  P872. 

P872:  Place  the  value  from  the  currently  P861  counter  onto  data 
element  (6)  of  the  data  elements  at  the  top  of  the  P516 
list. 

P873:  Oivide  the  value  that  is  equal  to  the  value  in  the  P860 
counter  divided  by  the  sum  of  the  values  from  the  P2 
counter  (number  of  time  slots  required  for  unscheduled 
tasks)  and  the  value  from  the  P4  counter  (number  of  time 
slots  required  for  already  scheduled  tasks).  This  value 
is  the  overall  ratio  (for  all  P177  list  entry  groups)  of 
the  time  slots  scheduled  versus  calendar  time  slots  used 
to  schedule  the  tasks  in  this  combination  of  task 


I 

I 
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scheduling  options,  when  breaks  and  time  between  tasks  is 
considered. 

P874:  Place  the  value  from  P873  onto  data  element  (5)  of  the 
data  elements  at  the  top  of  the  P516  list. 

P875:  Is  the  value  in  the  P861  counter  equal  to  'O'?  Yes  = 

P876;  No  (i.e.,  this  is  not  an  ideal  combination  of  task 
scheduling  options  and  therefore  the  search  for  other 
better  combinations  of  task  scheduling  options  will 
continue)  =  P880 

P876:  Identify  the  number  of  entries  on  the  P7  list  (number  of 
tasks  in  this  iteration  of  FNl). 

P877:  Identify  the  value  in  data  element  (Pd)  (number  of  tasks 
scheduled  in  this  combination  of  task  scheduling  options) 
at  the  top  of  the  P516  list.  Is  this  value  equal  to  the 
value  derived  in  P876?  Yes  -  P878;  No  =  P880 

P878:  Identify  the  value  in  data  element  (3d)  (tasks  that  need 
to  be  rescheduled  in  this  combination  of  task  scheduling 
options)  at  the  top  of  the  P516  list.  Is  this  value  'O'? 
Yes  =  P879;  No  (i.e.,  this  is  not  an  ideal  combination  of 
task  scheduling  options)  =  P880 

P879:  Identify  the  value  in  data  element  (4)  (number  of  time 

slots  tentatively  scheduled  in  not  the  preferred  time  use 
code  (CT11)).  Is  this  value  equal  to  'O'?  Yes  (i.e., 
this  is  an  'ideal'  scheduling  option)  =  P924;  No  (i.e., 
this  is  not  an  ideal  combination  of  task  scheduling 
options)  =  P880 

P880:  Is  the  flag  in  P491  a  'A'  or  a  '8'?  A  =  P881;  B  =  P886 

P881:  Change  the  P491  flag  to  a  'S'. 

P882:  Copy  each  of  the  P528  or  P 529  lists  with  a  list  label  as 
an  entry  on  the  current  P516  list  onto  a  P530  (i.e.,  task 
scheduling  option  in  the  best  combination  of  task 
scheduling  options  so  far)  list.  To  do  this,  simply  copy 
the  P528  or  P529  list  and  change  the  code  in  part  (3)  of 
the  label  in  the  new  P530  list  to  be  a  ' c ' .  Do  not  erase 
the  P528  or  P529  lists. 

P883:  Copy  the  P516  list  onto  a  P517  list. 

P884:  For  each  of  the  P526  lists  (tasks  needing  to  be 

rescheduled  if  the  task  scheduling  option  is  chosen)  for 
which  the  ID5  in  part  (1)  of  the  P526  label  is  an  entry  on 
the  P517  list,  change  the  code  in  part  (3)  of  the  P526 
label  to  be  a  'c'  (best  so  far). 
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P885 :  GO  TO  P637. 

P886:  Compare  the  value  in  data  element  (2a)  (currently  being 
scheduled  tasks  scheduled  in  this  combination  of  task 
scheduling  options)  in  the  data  elements  at  the  top  of  the 
P516  list  with  the  value  in  data  element  (2a)  at  the  top 
of  the  P517  list.  Is  the  P516  list  value  equal  to, 
greater  than  or  less  than  the  P517  list  value?  equal  to  = 
P 887 ;  greater  than  (i.e.,  the  combination  of  task 
scheduling  options  in  the  current  P516  list  is  not  as 
desirable  as  the  previously  identified  best  combination  of 
task  scheduling  options;  therefore,  the  P516  list 
combination  of  task  scheduling  options  will  not  be  used 
and  the  best  combination  of  task  scheduling  options  so 
far,  as  shown  on  the  P517  list,  remains  unchanged)  =  P637; 
less  than  (i.e.,  the  current  P516  list  value  is  better 
than  the  previous  best  value  shown  on  the  P517  list; 
therefore,  the  current  P516  combination  of  task  scheduling 
options  becomes  the  new  ‘best  so  far1  combination  of  task 
scheduling  options)  =  P882 

P887:  Compare  the  value  in  data  element  (6)  (P177  list  entry 
groups  with  the  calendar  scheduling  time  of  more  than 
twice  the  task  scheduling  time)  of  the  data  elements  at 
the  top  of  the  P516  list  with  the  value  in  data  element 
(6)  on  the  P517  list.  Is  the  P516  value  equal  to,  greater 
than  or  less  than  the  P517  value?  equal  to  =  P888; 
greater  than  =  P637;  less  than  =  P882 

P888:  Compare  the  value  in  data  element  (5)  (ratio  of  calendar 
time  to  task  scheduling  time)  of  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (5)  on 
the  P517  list.  Is  the  P516  list  value  equal  to,  greater 
than  or  less  than  the  P517  value?  equal  to  =  P889; 
greater  than  =  P882;  less  than  =  P637 

P889:  Compare  the  value  in  data  element  ( 7 i )  (number  of  dated 
tasks  that  need  to  be  rescheduled  in  this  combination  of 
task  scheduling  options)  in  the  data  elements  at  the  top 
of  the  P516  list  with  the  value  in  data  element  (7i)  on 
the  P517  list.  Is  the  P516  value  equal  to,  greater  than 
or  less  than  the  P517  list  value?  equal  to  =  P890; 
greater  than  =  P637;  less  than  =  P882 

P890:  Compare  the  value  in  data  element  (7j)  (total  tasks  that 
need  to  be  rescheduled)  in  the  data  elements  at  the  top  of 
the  P516  list  with  the  value  in  data  element  (7j)  on  the 
P517  list.  Is  the  P516  list  value  equal  to,  greater  than 
or  less  than  the  P517  value?  equal  to  =  P891;  greater 
than  =  P637;  less  than  =  P882 
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P891:  Compare  the  value  in  data  element  (7h)  (selected  tasks 
that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (7h) 
on  the  P517  list.  Is  the  P516  list  value  equal  to, 
greater  than  or  less  than  the  P517  value?  equal  to  = 
P892;  greater  than  =  P637;  less  than  =  P882 

P892:  Compare  the  value  in  data  element  (7g)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  lis*  with  the  value  in  data  element  (7g) 

on  the  P517  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P893;  greater  than  =  P637;  less  than  =  P882 

P893:  Compare  the  value  in  data  element  (7f)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (7f) 

on  the  P 517  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P894;  greater  than  =  P637;  less  than  =  P882 

P894:  Compare  the  value  in  data  element  (7e)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (7e) 

on  the  P517  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P895;  greater  than  =  P637;  less  than  =  P882 

P895:  Compare  the  value  in  data  element  (7d)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (7d) 

on  the  P5I7  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P896;  greater  than  =  P637;  less  than  =  P882 

P896:  Compare  the  value  in  data  element  (7c)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P5I6  list  with  the  value  in  data  element  (7c) 

on  the  P5I7  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P897;  greater  than  =  P637;  less  than  =  P882 

P897:  Compare  the  value  in  data  element  (7b)  (selected  tasks 
that  need  to  be  rescheduled)  in  the  data  elements  at  the 
top  of  the  P516  list  with  the  value  in  data  element  (7b) 

on  the  P517  list.  Is  the  P516  list  value  equal  to, 

greater  than  or  less  than  the  P517  value?  equal  to  = 
P898;  greater  than  =  P637;  less  than  =  P882 


P898:  Compare  the  value  in  data  element  (7a)  (selected  tasks 

that  need  to  be  rescheduled)  in  the  data  elements  at  the 


STEP  F4A-3 


top  of  the  P516  list  with  the  value  in  data  element  (7a) 
on  the  P517  list.  Is  the  P516  list  value  equal  to, 
greater  than  or  less  than  the  P517  value?  equal  to  = 

P899;  greater  than  =  P637;  less  than  =  P882 

P899:  Compare  the  value  in  data  element  (2c)  (future  scheduled 
tasks  scheduled  in  this  combination  of  task  scheduling 
options)  in  the  data  elements  at  the  top  of  the  P516  list 
with  the  value  in  data  element  (2c)  on  the  P517  list.  Is 
the  P516  list  value  equal  to,  greater  than  or  less  than 
the  P517  value?  equal  to  =  P900;  greater  than  =  P882; 
less  than  =  P637 

P900:  Compare  the  value  in  data  element  (4)  (incorrect  time  use 
time  slots)  of  the  data  elements  at  the  top  of  the  P516 
list  with  the  value  in  data  element  (4)  on  the  P517  list. 
Is  the  P516  list  value  equal  to,  greater  than  or  less  the 
P517?  equal  to  =  P901;  greater  than  =  P637;  less  than  = 
P882 

P901:  Compare  the  value  in  data  element  (1)  (number  of  pairs  of 
1027s  used  in  the  scheduling  of  the  tasks  in  this 
combination  of  task  scheduling  options)  at  the  top  of  the 
P516  list  with  the  value  in  data  element  (1)  on  the  P517 
list.  Is  the  P516  value  equal  to,  greater  than  or  less 
than  the  P517  value?  equal  to  =  P637;  greater  than  = 

P637;  less  than  =  P882 

P902:  (From  P649):  Are  there  any  entries  on  the  P516  list?  Yes 
=  P903;  No  =  P907 

P903:  Is  the  P491  flag  a  'A'  or  a  'B1?  A  =  P904;  B  =  P907 

P904:  Copy  each  of  the  P528  or  P529  lists  with  a  list  label  that 
is  an  entry  on  the  current  P516  list  onto  a  P530  list 
(i.e.,  the  task  scheduling  option  list  for  the  tasks  in 
the  best  combination  of  task  scheduling  options  so  far). 

To  do  this,  simply  copy  the  P528  or  P529  list  and  change 
the  code  in  part  (3)  of  the  label  of  the  new  P530  list  to 
be  a  ' c 1 . 

P9U5:  Copy  the  P516  list  to  a  P517  list  (best  combination  of 
task  scheduling  options  so  far). 

P906:  For  each  of  the  P526  lists  (tasks  that  need  to  be 

rescheduled  (for  which  the  ID5  in  part  (1)  of  the  P526 
label  is  an  entry  on  the  P517  list,  change  the  code  in 
part  (3)  of  the  P526  list  label  to  be  a  ’ c *  (best  so  far). 

P9U7:  Erase  ail  P528  and  P529  lists.  Also  erase  all  P526  lists 
with  a  code  of  ' b ‘  in  part  (3)  of  the  label  of  the  P526 
list.  Also  erase  the  P516  list.  The  P530  lists  (the 
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labels  for  which  are  shown  on  the  P517  list),  i.e.,  the 
task  scheduling  options  and  the  best  combination  of  task 
scheduling  options  so  far,  are  the  task  scheduling  options 
that  will  be  used  for  scheduling. 

P908:  Is  the  value  in  data  element  (2a)  (currently  being  tasks 
tentatively  scheduled  in  this  combination  of  task 
scheduling  options)  on  the  top  of  the  P517  list  equal  to 
'O'?  Yes  (i.e.,  it  was  not  possible  to  identify  any 
acceptable  scheduling  options  for  any  of  the  currently 
being  scheduled  tasks  in  this  iteration  of  FN 1  and, 
therefore,  no  tasks  will  be  scheduled  in  this  iteration  of 
FNl)  =  FN1.25  (P909) ;  No  =  P1032 

FN1.25:  FOR  each  of  the  entries  (task  identifiers  (ID23s))  on 
the  P26  (already  scheduled  tasks)  list: 

P909:  Identify  the  entry  on  the  R2  list  from  PI  with  the  ID23  in 
this  iteration  of  FNl. 25  in  data  element  (1). 

P910:  Identify  the  requirement  application  identifier  (ID5)  in 
data  element  (3)  of  the  R2  list  entry  located  in  P909. 

P911:  Remove  the  ID5  identified  in  P910  from  the  P7  (all  tasks) 

1  ist. 

P912:  Erase  the  entire  R2  list  entry  (all  11  data  elements) 
located  in  P909  from  the  R2  list  located  in  PI. 

P913:  NEXT  FNl. 25;  end  of  FNl. 25,  GO  TO  P914. 

P914:  Is  there  now  more  than  one  entry  on  the  P7  list?  Yes  = 
P50;  No  =  P51 

FNl. 26:  FOR  each  P526  list: 

FNl. 26.1:  FOR  each  entry  (task  identifier  ( 1 02 3 ) )  on  the  P526 
list  for  this  iteration  of  FNl. 26: 

P915:  Locate  the  DS24  data  corresponding  to  the  ID23  for  this 
iteration  of  FNl. 26.1. 

P916:  Change  the  answer  to  the  question  as  to  whether  the  task 

in  this  iteration  of  FNl. 26.1  has  been  scheduled  (i.e.,  an 
answer  to  one  of  the  questions  on  the  DS24  data  located  in 
P915)  to  be  'No'  and  enter  the  code  of  'C'  (task  not 
scheduled  because  it  needs  to  be  rescheduled)  as  the 
explanation  for  why  the  task  is  not  scheduled. 

P917:  Identify  the  start  time  slot  information  about  the  task 
in  this  iteration  of  FNl. 26.1  on  the  DS24  data  from  P915, 
i.e.,  identify  the  time  the  task  was  previously  scheduled 
to  start. 
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P918:  Locate  the  DS 27  data  corresponding  to  the  ID27  that  is 

part  (1)  of  the  start  time  slot  information  identified  in 
P 197.  Locate  the  time  slot  on  this  DS27  data 
corresponding  to  the  day  and  time  slot  number  that  are 
parts  (2)  and  (3)  of  the  start  time  slot  information 
located  in  P917. 

P919:  Beginning  with  the  time  slot  located  in  P 91 8  and  following 
to  each  successive  time  slot  (as  identified  on  the  DS27 
data  for  the  time  slot)  erase  the  scheduling  information 
for  the  task  in  this  iteration  of  FNl.26.1  from  the  DS27 
data  and  any  successive  DS27  data  sets  identified  on  the 
time  slot  information  identified  in  P918. 

P920:  Erase  all  of  the  scheduling  information  (e.g.,  start  and 
stop  times,  whether  schedule  before  due  date,  number  of 
interruptions,  etc.)  from  the  0S24  data  located  in  P915. 

P921:  Place  the  1023  for  this  iteration  of  FNl.26.1  on  the  DL39 

list. 

P922:  NEXT  FNl.26.1;  end  of  FNl.26.1,  GO  TO  P923. 

P923:  NEXT  FN1.26;  end  of  FN1.26,  GO  TO  FNl.27  (P929). 

P924:  (From  P879):  Is  the  P491  flag  a  ’A’  or  a  1 B 1 ?  A  =  P925; 

B  =  P928 

P925:  Copy  each  of  the  P528  or  P529  lists  with  a  list  label  that 
is  an  entry  on  the  current  P516  list  onto  a  P530  list 
(i.e.,  the  task  scheduling  option  list  for  the  tasks  in 
the  best  combination  of  task  scheduling  options  so  far). 

To  do  this,  simply  copy  the  P528  or  P529  list  and  change 

the  code  in  part  (3)  of  the  label  of  the  new  P530  list  to 

be  a  ' c ' . 

P926:  Copy  the  P516  list  to  a  P517  list  (best  combination  of 
task  scheduling  options  so  far). 

P927:  For  each  of  the  P526  lists  (tasks  that  need  to  be 

rescheduled  (for  which  the  ID5  in  part  (1)  of  the  P526 
label  is  an  entry  on  the  P517  list,  change  the  code  in 
part  (3)  of  the  P526  list  label  to  be  a  'c1  (best  so  far). 

P928:  Erase  all  P528  and  P529  lists.  Also  erase  all  P626  lists 
with  a  code  of  'b‘  in  part  (3)  of  the  label  of  the  P526 
list.  Also  erase  the  P5Ib  list.  The  P530  lists  (the 
labels  for  which  are  shown  on  the  P617  list),  i.e.,  the 
task  scheduling  options  and  the  best  combination  of  task 
scheduling  options  so  far,  are  the  task  scheduling  options 
that  will  be  used  for  scheduling. 
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FNl.27:  FOR  each  P517  list  entry: 

P929:  Identify  the  code  ('a'  or  1 b 1 )  in  data  element  (3)  of  the 
P517  list  entry  for  this  iteration  of  FN 1.27.  Is  this 
code  a  ‘ b '  (currently  being  formed)?  Yes  =  P930;  No  = 

P941  (next  FNl.27) 

P930:  Identify  the  ID5  in  data  element  (1)  of  the  P517  list 
entry  for  this  iteration  of  FNl.27. 

P931:  Locate  the  P530  list  with  the  IDS  from  P930  as  the  first 
part  of  its  label . 

P932:  Identify  the  code  (1-3)  in  data  element  (1)  (whether  being 
currently  scheduled,  already  scheduled  or  future  scheduled 
task)  at  the  top  of  the  P530  list  located  in  P931.  Is 
this  code  a  ' 2 ‘ ?  Yes  =  P933;  No  =  P941  (next  FNl.27) 

P933:  Locate  the  R2  list  entry  with  the  ID5  from  P930  in  its 
data  element  (3). 

P934:  Identify  the  task  identifier  (ID23)  in  data  element  (1)  of 
the  R2  list  entry  from  P933. 

P935:  Locate  the  DS24  data  corresponding  to  the  ID23  from  P934. 

P 936 :  Change  the  answer  to  the  question  as  to  whether  the  task 
in  this  iteration  of  FNl.27  has  been  scheduled  (given  on 
the  DS24  data  located  in  P935)  to  be  'No'  and  enter  the 
code  of  'C'?  Task  not  scheduled  because  it  needs  to  be 
rescheduled)  as  the  explanation  for  why  the  task  is  not 
scheduled . 

P937:  Identify  the  start  time  slot  information  about  the  task  in 
this  iteration  of  FNl.27  on  the  DS24  data  from  P935,  i.e., 
identify  the  time  that  the  task  was  previously  scheduled 
to  start. 

P938:  Locate  the  DS27  data  corresponding  to  the  ID27  that  is 

part  (1)  of  the  start  time  slot  information  identified  in 
P937.  Locate  the  time  slot  on  this  DS27  data 
corresponding  to  the  day  and  time  slot  number  that  are 
parts  (2)  and  (3)  of  the  start  time  slot  information 
located  in  P937. 

P939:  Beginning  with  the  time  slot  located  in  P938  and  following 
to  each  successive  time  slot  (as  identified  on  the  DS27 
data  for  the  time  slot)  erase  the  scheduling  information 
for  the  task  in  this  iteration  of  FNl.27  from  the  DS27 
data  sets. 
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P940:  Erase  all  of  the  scheduling  information  (e.g.,  start  and 
stop  time,  whether  the  task  was  scheduled  before  the  due 
date,  etc.)  from  the  DS27  data  located  in  P935. 
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P941:  NEXT  FNl.27;  end  of  FNl.27,  GO  TO  P942. 

P 942 :  Is  the  value  in  data  element  (2c)  (future  scheduled  tasks 
scheduled  in  this  combination  of  task  scheduling  options) 
at  the  top  of  the  P517  list  a  'O'?  Yes  =  FNl.28  (P943); 

No  =  FNl.29  (P966) 

FNl.28:  FOR  each  entry  (i.e.,  each  P528/P529  list  label)  on  the 
P517  list: 

P943:  Identify  the  requirement  application  identifier  (ID5)  in 

data  element  (1)  of  the  P517  list  entry  for  this  iteration 
of  FNl.28. 


P944:  Locate  the  P530  list  with  the  ID5  from  P943  as  the  first 
part  of  this  label . 

P945:  Identify  the  code  (1-3)  in  data  element  (1)  at  the  top  of 
the  P530  list  located  in  P944.  Is  this  code  a  '3'  (future 
scheduled  task)?  Yes  =  P946;  No  =  P965  (next  FNl.28) 

P946:  Locate  the  DS4  data  corresponding  to  the  ID5  from  P943. 
Identify  the  DS1  data  corresponding  to  the  requirement 
identifier  (ID6),  if  any,  on  this  D34  data. 

P947:  Generate  a  new  DS5  data  set  based  on  the  DS4  data  and  DS 1 
data  from  P946;  assign  the  next  available  requirement 
implementation  identifier  (109)  from  R7. 

P948:  Is  the  DS4  data  from  P946  Reminder  Notice  type  of  suspense 

data  (i.e.,  not  a  requirement)?  (Note:  This  is  shown  on 
the  0S4  data.)  Yes  =  P949;  No  =  P951 

P949:  Add  the  ID9  assigned  in  P947  for  the  new  DS5  data  to  the 
0L9  list. 

P950 :  GO  TO  P952. 

P951:  Add  the  ID9  assigned  to  the  newly  generated  DS5  data  in 
P947  onto  the  DL3  list. 

P9b2:  Calculate  the  new  ‘next  suspense  date'  for  the  DS4  data 
from  P946  (using  the  'suspense  interval'  data  on  the  DS4 
data).  Is  this  new  next  suspense  date  later  than  the 
'last  suspense  date'  on  the  D34  data?  Yes  =  P953;  No  = 
P955 
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P953:  Deactivate  the  DS4  data,  i.e.,  place  the  current  date  (R5) 
in  the  deactivation  date  for  the  DS4  data  and  remove  the 
ID5  identifying  the  DS4  data  from  the  DLll  list.  Delete 
the  entry  for  the  ID5  identified  in  P943  from  the  DL32 
list. 

P954:  GO  TO  P956. 

P955:  Replace  the  old  'next  suspense  date'  on  the  DS4  data  from 
P946  with  the  new  'next  suspense  date'  calculated  in  P952. 

P956:  Loco  the  entry  on  the  R2  list  from  PI  that  contains  the 
IDS  identified  in  P943  in  its  data  element  (3). 

P957:  Identify  the  task  type  code  (CT8)  in  data  element  (6)  of 
the  R2  list  entry  located  in  P956. 

P958:  Locate  the  0S23  data  corresponding  to  the  CT8  identified 

in  P957.  Also  locate  the  DS25  data,  if  any,  corresponding 
to  this  CT8. 

P959:  Using  the  DS23  data  and  the  DS25  data  from  P958,  generate 
a  new  set  of  DS24  data  for  the  future  scheduled  task  the 
scheduling  of  which  is  shown  on  the  P530  list  located  in 
P944.  (Follow  the  instructions  given  in  P4  of  Step 
F4A-1.)  Assign  the  next  available  task  identifier  (ID23) 
from  R8  to  the  new  DS24  data.  The  ID9  placed  on  the  new 
DS24  data  should  be  the  ID9  assigned  to  the  new  DS5  data 
generated  in  P947. 

P96U.  Fill  in  data  element  (1)  on  the  R2  list  entry  located  in 
P956  with  the  task  identifier  (ID23)  assigned  to  the  new 
DS24  data  generated  in  P959.  Also  enter  this  ID23  onto 
data  element  (13)  of  the  data  elements  at  the  top  of  the 
P530  list  located  in  P944. 

P961:  Add  the  ID23,  the  OHMIS  service  area  identif  ier  ( ID 10 )  and 
ID9  assigned  to  the  new  DS4  data  onto  the  DL38  list. 

P962:  Add  the  ID23,  the  I D 10  and  the  requirements  implementation 
units  assigned  to  the  new  DS24  data,  and  the  answer  of 
'Yes'  (whether  this  is  an  'employee  transport'  type  of 
task)  to  the  DS36  list. 

P963:  Add  the  1023,  the  I D 10  and  facility  identifier  (IDS),  if 
any,  assigned  to  the  new  DS24  data  to  the  DL37  list. 

P9b4:  Add  tne  CT8  from  P9b7  and  the  11)23  assigned  in  generating 
the  new  D824  data  to  the  [)S 5  data  generated  in  P947. 

P96h:  NEXT  Fill. 28;  end  of  FNl.28,  GO  TO  fNl.29  ia’9661. 
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FN 1 .29:  FOR  each  entry  on  the  P517  list: 

1  1  :  identify  the  ID5  in  data  element  (1)  of  the  P 51 7  list 
entry  for  this  iteration  of  FNl.29. 

P96 7 :  Locate  the  P530  list  with  the  ID5  from  P966  in  part  (1)  of 
its  label . 

P968:  Identify  the  1023  in  data  element  (13)  at  the  top  of  the 
P530  list  from  P967. 

P969:  Locate  the  0S24  data  correspond ing  to  the  ID23  identified 
in  P968 . 

P970:  Using  the  P530  list  located  in  P967,  begin  to  enter 

scheduling  information  for  the  task  identified  in  P968. 
First  complete  the  DS24  data.  Answer  the  question  on  the 
DS24  data  as  to  whether  the  user  specified  the  schedule  as 
'No'.  Answer  toe  question  as  to  whether  it  was  possible 
to  schedule  the  task  as  'Yes'  (change  the  previous  answer 
of  'No'  and  remove  the  code  explaining  why  it  was  not 
possible  to  schedule  this  task  from  the  DS24  data).  For 
the  start  time  slot  information,  enter  the  time  slot 
information  in  data  element  (2)  of  the  first  entry  on  the 
P530  list  located  in  P967.  For  the  end  time  slot,  use  the 
time  slot  information  in  data  element  (2)  in  the  last 
entry  on  the  P530  list.  For  the  total  number  of  time 
slots  actual 1y  scheduled  and  the  total  number  of 
interruptions  required  for  the  scheduling  of  the  task,  use 
the  value  in  data  element  (2)  and  (3)  at  the  top  of  the 
P530  list.  Answer  the  question  about  whether  the  task  was 
scheduled  after  the  due  date  as  'No'.  Answer  the  question 
about  whether  it  was  possible  to  schedule  the  task  during 
the  preferred  time  use  (C Til )  as  ’Yes’,  if  the  answer  in 
data  element  (8)  on  each  entry  on  the  P530  list  from 
P 96 7  was  'Yes';  if  there  is  an  answer  of  'No'  in  data 
element  (8)  for  any  entry  on  the  P530  list,  answer  the 
question  'No' . 

P971:  Identify  the  code  (1-3)  in  data  element  (1)  at  the  top  of 
the  P53U  list  located  in  P967.  Is  the  code  a  '1',  '2'  or 
'3'?  1  =  P974;  2  =  P976;  3  =  P972 

P972:  Remove  the  ID5  identified  in  P966  from  the  P29  list. 

P973:  GO  TO  P981. 

P974:  Remove  the  ID23  identified  in  P968  from  the  P21  list. 

P 975 :  GO  TO  P9/7. 


P976:  Remove  the  1023  identified  in  P968  from  the  P26  list. 


P977: 

Is  the 
P979 

ID23 

from  P968  on  the 

DL  31 

list? 

Yes  =  P978;  No 

P978: 

Remove 

the 

ID23  identified  in 

P968 

from 

the  DL 31  list. 

P  979 : 

Is  the 
P981 

ID23 

from  P968  on  the 

DL39 

list? 

Yes  =  P980;  No 

P980: 

Remove 

the 

1023  identified  in 

P968 

from 

the  DL39  list. 

P981 : 

Remove 

the 

ID5  identified  in 

P966 

from 

the  P7  list. 

FN1.29. 

1:  FOR 

each 

entry  on  the  P530 

list 

located  in  P967: 

P982:  Identify  the  1027  contained  in  part  (1)  of  the  time  slot 
information  given  in  data  element  (2)  of  the  P530  list 
entry  for  this  iteration  of  FNl.29.1. 

P983:  Locate  the  0S27  data  corresponding  to  the  ID27  from  P982. 

P984:  On  the  0S27  data  from  P983,  locate  the  time  slot 

equivalent  to  part  (2)  (day)  and  part  (3)  (time  slot 
number)  of  the  data  element  (2)  on  the  P530  list  entry  for 
this  iteration  of  FNl.29.1. 

P985:  Fill  in  the  empty  fields  in  the  time  slot  identified  in 
P984  on  the  D327  data  located  in  P983  as  follows:  The 
task  identifier  should  be  the  ID23  from  P968.  The  answer 
as  to  whether  this  task  needs  a  Scheduling  Notice  is 
’Yes'.  The  time  use  code  is  from  data  element  (9)  at  the 
top  of  the  P530  list  located  in  P967.  The  answer  as  to 
whether  the  task  was  scheduled  at  the  specification  of  the 
user  is  'No'.  The  answer  as  to  whether  there  are  any 
restrictions  for  the  scheduling  of  the  .;rk  is  given  in 
data  element  (11)  at  the  top  of  the  P530  ,ist  located  in 
P967.  The  total  standard  hours  for  completing  the  task 
is  given  in  data  element  (12)  at  the  top  of  the  P530  list. 
The  user  specified  hours  for  scheduling  the  task  is  only 
known  for  'already  scheduled'  tasks,  i.e.,  tasks  having 
the  code  of  '2'  (as  identified  in  P971).  This  value  is  on 
the  DS24  data.  If  the  code  was  not  a  ’21,  the  user 
specified  hours  for  scheduling  is  the  same  as  the  standard 
hours  for  scheduling.  The  actual  hours  for  scheduling 
the  task  is  given  in  data  element  (2)  at  the  top  of  the 
P53U  list  from  P968.  The  cumulative  number  of  time  slots 
scheduled  for  the  task  and  the  cumulative  number  of 
interruptions  as  of  the  time  slot  for  scheduling  the  task 
represented  by  this  iteration  of  FNl.29.1  is  given  on  data 
elements  (4)  and  (5)  of  the  P530  list  entry  for  this 
iteration  of  FNl.29.1.  The  time  slot  for  the  next  time 
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same  as  the  value  for  this  iteration  of  FNl.31?  Yes  = 
P999;  No  =  P1019  (next  FNl.31.1) 

P999:  Identify  the  code  (1-3)  in  data  element  (2)  of  the  R2  list 
entry  for  this  iteration  of  FNl.31.1.  Is  this  code  a  '1' 
or  '3'?  (Note:  The  code  cannot  have  been  a  '2'.)  1  = 

P 1000 ;  3  =  P1017 

P1000:  Identify  the  task  type  code  (CT8)  in  data  element  (6)  and 
the  OHMIS  service  area  identifier  (ID10)  in  data  element 
(5)  on  the  R2  list  for  this  iteration  of  FNl.31.1. 

P 1001 :  Identify  the  employee  identifiers  (ID4s)  on  the  DL34  list 
for  the  CT8  and  I DIO  from  P1000. 

FNl.31. 1.1:  FOR  each  104  identified  in  P1001: 

P1002:  Examine  the  0L40  list  and  determine  whether  there  are  any 
entries  (weekly  schedule  identifiers  (1028s))  for  the  ID10 
from  P 1001  and  the  104  for  this  iteration  of  FNl.31. 1.1. 
Yes  =  P 1012 ;  No  =  P1003 

P1003:  NEXT  FNl.31. 1.1;  end  of  FNl.31. 1.1,  GO  TO  P1004. 

P1004:  IDENTIFY  the  task  identifier  (ID23)  in  data  element  (1)  of 
the  R2  list  entry  for  this  iteration  of  FNl.31.1. 

P1005:  Locate  the  0S24  data  corresponding  to  the  ID23  from  P1004. 

P1006:  Answer  the  question  on  the  DS24  data  from  P1005  about 

whether  the  task  was  scheduled  as  'No’  and  put  the  code 
* B *  (cannot  schedule,  because  there  is  no  weekly  schedule 
data  (0S26)  for  any  of  the  persons  qualified  to  perform 
the  task)  on  the  0524  data  from  P1005.  Also  determine  if 
the  ID23  identified  in  P1004  is  on  the  0L31  list,  and,  if 
not,  place  the  1023  on  the  DL31  list. 

P1007:  Remove  the  ID23  identified  in  P1004  from  the  P21  list. 

P10U8:  Identify  the  105  in  data  element  (3)  of  the  R2  list  entry 
for  this  iteration  of  FNl.31.1. 

P1009:  Remove  the  105  identified  in  P1008  from  the  P7  list.  GO 
TO  P1U19  (next  FNl.31.1). 

P1010:  Erase  the  entire  R2  list  entry  for  this  iteration  of 
FNl.31.1  from  the  R2  list  located  in  PI. 

P 101 1 :  GO  TO  P 1019  (next  FNl.31.1). 

P 101 2 :  Identify  the  105  in  data  element  (3)  of  the  R2  list  entry 
for  this  iteration  of  FNl.31.1. 
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slot  in  which  this  task  is  scheduled  is  given  in  data 
element  (2)  of  the  next  P530  list,  if  any,  i.e.,  the 
P530  list  entry  for  the  next  iteration  of  FNl.29.1.  If 
this  is  the  last  P530  list  entry,  this  information  should 
be  left  blank  on  the  DS27  data. 

P986:  NEXT  FNl.29.1;  end  of  FNl.29.1,  GO  TO  P987. 

P987:  Erase  the  P530  list  identified  in  P967. 

P988:  Locate  the  entry  on  the  R2  list  from  PI  with  the  ID5  from 
P966  as  its  data  element  (1). 

P989:  Erase  the  entire  R2  list  entry  (all  11  data  elements) 
located  in  P988  from  the  R2  list  located  in  Pi. 

P990:  NEXT  FN1.29;  end  of  FNl.29,  GO  TO  P40. 

P 991 ;  (From  P490):  Start  a  list,  called  the  P991  list.  This 

list  will  contain  the  labels  of  P476  lists,  i.e.,  the  user 
group  numbers  from  data  element  (11)  on  the  R2  list 
entries . 

FN1.30:  FOR  each  entry  on  the  P402  list  (i.e.,  for  each  user 

group  number  from  data  element  (11)  on  an  R2  list  entry: 

P992:  Locate  the  P476  list  entry  with  the  value  from  this 
iteration  of  FN1.30  as  its  label. 

P993:  Examine  the  P476  list  located  in  P992.  Does  this  list 

have  any  entries  on  it,  i.e.,  is  the  value  in  the  data 

element  at  the  top  of  the  P476  list  indicating  the  number 
of  entries  on  the  list  greater  than  ’0‘?  Yes  =  P995  (next 
FN1.30);  No  =  P994 

P994:  Put  the  value  for  this  iteration  of  FN1.30  onto  the  P991 
list. 

P995 :  NEXT  FN1.30;  end  of  FNl.30,  GO  TO  P996. 

P996:  Are  there  any  entries  on  the  P991  list?  Yes  =  P 99 7 ;  No  = 
P491 

P997:  Start  a  list,  called  the  P997  list.  This  list  will 
contain  ID5s. 

FN1.31:  FOR  each  entry  on  the  P991  list: 

FNl.31.1:  FOR  each  entry  on  the  R2  list  located  in  PI: 

P998:  Examine  the  value  in  data  element  (11)  on  the  R2  list 

entry  for  this  iteration  of  FNl.3i.l.  Is  the  value  the 
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P 10 1 3 :  Erase  the  105  identified  in  P1Q12  from  the  P7  list. 

P 10 1 4 :  Erase  the  ID23  identified  in  P1004  from  the  P21  list. 

P1015:  Place  the  105  on  the  P997  list. 

P1016:  60  TO  P1019  (next  FN1.31.1). 

P1017:  Identify  the  ID5  in  data  element  (3)  of  the  R2  list  entry 
for  this  iteration  of  FN 1.31.1. 

P 10 1 8 :  Erase  the  105  identified  in  P 101 7  from  the  P29  list.  GO 
TO  PI010. 

P1019:  NEXT  FNl.31.1;  end  of  FNl.31.1,  60  TO  P1020. 

P1020:  NEXT  FNl.31;  end  of  FN1.31,  60  TO  P1021. 

P 1021 :  Are  there  now  any  entries  on  the  P21  (currently  being 
scheduled  tasks)  list?  Yes  =  P1022;  No  =  P41 

P1022:  Are  there  any  entries  on  the  P997  list?  Yes  =  FN 1 . 32 
(P1026) ;  No  =  P1023 

P1023:  Is  the  1023  for  this  iteration  of  FNl  on  the  P21  list? 

Yes  =  P491;  No  =  PI024 

P 10 24 :  Change  the  task  identifier  (ID23)  that  is  the  1 abel  on 

the  R2  list  from  PI  (i.e.,  for  this  iteration  of  FNl)  to 
be  one  of  the  ID23s  on  the  P21  list). 

P1025:  Locate  the  ID23  for  this  iteration  of  FNl  on  the  R1  list 
(i.e.,  on  the  Step  F4A-2  P25  list)  and  replace  the  1023 
with  the  1023  used  in  P1024  to  relabel  the  R2  list  from 
PI.  (Note:  It  is  important  that  this  new  label  (ID23)  on 
the  R1  list  be  put  in  the  same  spot  on  the  list  as  the 
1023  for  this  iteration  of  FNl,  not  at  the  end  of  the  R1 
list.  If  this  is  not  done,  the  program  will  repeat 
itself,  because  the  program  arrive  at  the  1023  from  the 
relabeled  R2  list  a  second  time.)  Also,  replace  the  ID23 
for  this  iteration  of  FNl  with  the  ID23  used  in  P 1024  to 
relabel  the  R2  list  from  PI.  That  is,  change  the  1023  for 
this  iteration  of  FNl  so  that  the  program  will  consider 
this  iteration  of  FNl  to  be  processing  the  group  of  task 
with  the  new  label  identified  in  P1024.  This  is 
rational,  because  the  R2  list  being  processed  in  this 
iteration  of  FNl  has  not  changed,  only  the  label  for  this 
R2  list  has  changed.  60  TO  P 491 . 

FNl. 32:  FOR  each  entry  on  the  P997  list: 


STEP  F4A-3 


P1026:  Locate  the  entry  (i.e.,  set  of  11  data  elements)  on  the  R2 
list  from  PI  for  the  ID5  for  this  iteration  of  FN1.32. 

P1027:  Identify  the  task  identifier  (1D23)  in  data  element  (1)  on 
the  R2  list  entry  located  in  P1026. 

P1028:  Generate  a  new  R2  list  (i.e.,  a  new  Step  F4A-2  P24  list). 
Put  the  ID23  from  P1027  as  the  label  on  the  new  R2  list. 
Copy  the  R2  list  entry  from  this  iteration  of  FN1.32  (as 
located  in  P1026)  onto  the  new  R2  list  as  the  first  (and 
only)  entry  (set  of  11  data  elements)  on  the  new  R2  list. 
(Generate  a  new  R2  list  each  time  P1028  is  executed,  i.e., 
do  not  erase  previously  generated  R2  lists.  Treat  the  R2 
lists  as  though  they  were  generated  in  P24  of  Step  FA-2.) 

P1029:  Remove  the  entire  data  entry  (all  11  data  elements)  for 
the  R2  list  data  entry  located  in  P1026  from  the  R2  list 
located  in  PI. 

P1030:  Add  the  1023  for  this  iteration  of  FNl .32  to  the  R3  list 
(i.e.,  the  Step  F4A-2  P68  list  of  labels  of  P24/R2  lists 
that  contain  only  one  task). 

P1031:  NEXT  FNl. 32;  end  of  FNl. 32,  GO  TO  P491. 

P1032:  Are  there  any  P526  lists?  Yes  =  FNl. 33  (P1033);  No  = 

FNl. 27  (P929) 

FNl. 33:  FOR  each  P526  list: 

FNl. 33.1:  FOR  each  entry  (task  identifier  (1023))  on  the  P526 
list  for  this  iteration  of  FNl. 33: 

P1U33:  Locate  the  0S24  data  corresponding  to  the  ID23  for  this 
iteration  of  FNl. 33.1. 

P1034:  Identify  the  start  time  slot  information  for  the  task  in 
this  iteration  of  FNl. 33.1  on  the  DS24  data  from  P1033, 
i.e.,  identify  the  time  that  this  task  was  previously 
scheduled  to  start. 

P1035:  Using  the  0S24  data  located  in  P 1033 ,  determine  whether 

the  task  for  this  iteration  of  FNl. 33.1  has  more  than  one 
person  scheduled  to  perform  the  task.  Yes  =  P 1036 ;  No  = 
FNl. 2b  ( P915  ) 

P1036:  Identify  the  up  to  3  monthly  schedule  identifiers  (1D27) 

on  the  DS24  data  located  in  P 10 33  that  specify  the  monthly 
schedule  data  (DS27)  on  which  the  scheduling  for  the  task 
for  the  addition  persons  scheduled  to  perform  the  task  is 
shown  to  start.  Put  the  starting  ID27s  on  a  temporary 
list,  called  the  P 1036  list. 
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FN1.33.1.1:  FOR  each  ID27  on  the  P1036  list: 

P1037:  Locate  the  DS27  data  corresponding  to  the  1027  for  this 
iteration  of  FNl.33.1.1. 

FNl. 33. 1,1.1:  FOR  each  time  slot  in  which  the  task  in  this 
iteration  of  FNl. 33.1  is  already  scheduled  and  is, 
therefore,  also  to  be  scheduled  for  an  additional  person 
to  perform  the  task  at  the  same  time,  beginning  with  the 
date  of  the  month  and  the  time  slot  number  that  are  parts 
(2)  and  (3)  of  the  start  time  slot  identified  in  P1034  on 
the  DS27  data  located  in  P 1037  and  continuing  with  the 
time  slot  identified  in  P1040. 

P1038:  Locate  the  time  slot  for  this  iteration  of  FNl. 33. 1.1.1. 
(Follow  the  instructions  given  in  P15  of  Step  F4B-1.) 

P1039:  Determine  whether  the  scheduling  of  the  task  continues  to 
another  time  slot.  (This  information  is  shown  on  the  DS27 
data  for  the  time  slot  for  this  iteration  of  FNl. 33. 1.1.1 
as  located  in  P1038.)  Yes  =  P1040;  No  =  P1043  (next 
FNl. 33. 1.1) 

P1040:  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  will  continue.  (From  the  DS27  data  for  the  1038 
time  slot. ) 

P1041:  Erase  all  of  the  scheduling  information  for  the  task  in 
this  iteration  of  FNl. 33.1  from  the  DS27  data  time  slot 
located  in  P1038. 

P1042:  NEXT  FNl . 33 . 1 . 1 . 1 .  (End  of  FNl. 33. 1.1.1  will  not  be 
reached. ) 

P1043:  NEXT  FNl. 33. 1.1,  end  of  FNl. 33. 1.1,  GO  TO  P1044. 

P1044:  Change  the  answer  to  the  question  on  the  DS24  data  located 
in  P1033  about  whether  there  are  additional  persons 
scheduled  to  perform  this  task  to  be  'No'.  Erase  the 
information  about  the  additional  persons  previously 
scheduled  to  perform  this  tsk  shown  on  the  DS24  data. 

P1045 :  GO  TO  FNl. 26  (P915). 

P1046:  NEXT  FNl;  end  of  FNl,  GO  TO  P1047. 

P1047:  Are  there  any  entries  on  the  R4  list  (i.e.,  the  Step 
F4A-2,  P71  list  of  labels  of  P 24  ( R 2 )  lists  containing 
groups  of  employee  transport  tasks,  none  of  which  are 
'already  scheduled'  tasks)?  Yes  =  P1048;  No  =  P1049 

P1048:  GO  TO  PI  of  Step  F4A-4. 
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P1049:  Are  there  any  entries  on  the  R3  list  (i.e.,  the  Step  F4A-2 
P68  list  of  labels  of  P24  (R2)  lists  containing  only  one 
employee  transport  task)?  Yes  =  P1050;  No  =  P 105 1 

P1050:  GO  TO  PI  of  Step  F4A-5. 

P1051 :  GO  TO  P15  of  Step  F4A-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS5:  Requirements  implementation  data 

DS24:  Specific  task  scheduling  data 

(Note:  No  Scheduling  Notices  (015)  outputs  are  generated  in  Step 
F4A-3,  because  the  newly  scheduled  tasks  all  begin  at  the  same 
time  or  after  a  'already  scheduled1  task  for  which  the 
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In  this  Step,  the  groups  of  employee  transport  tasks  (i.e.,  more 
than  one  task  for  a  given  employee)  that  do  not  include  any  'already 
scheduled1  tasks  are  scheduled.  The  processing  for  this  Step  is  very 
similar  to  that  of  Step  F4A-3  and  will  not,  therefore,  be  repeated 
here.  As  with  all  other  scheduling  steps  in  Function  F4A  (i.e..  Steps 
F4A-3  through  F4A-7)  the  program  attempts  to  optimize  the  scheduling 
for  the  task  by  first  attempting  to  schedule  the  task  with  the  most 
rigid  scheduling  selection  criteria  (e.g.,  no  interruptions ,  preferred 
time  use,  etc.)  and,  failing  that,  make  successive  attempts  to 
schedule  the  tasks,  each  with  less  rigid  scheduling  selection 
criteria. 

The  major  differences  between  Step  F4A-4  and  Step  F4A-3  are: 

0  Like  Step  F4A-3,  Step  F4A-4  processes  data  using  a  series 
of  lists  of  information  about  the  tasks,  where  all  of  the 
tasks  on  the  same  list  are  employee  transport  tasks  for 
the  same  employee.  These  lists  were  formed  in  Step  F4A-2 
and  were  referred  to  as  P24  lists  in  that  Step  (the  name 
was  changed  to  ' R2  lists'  in  Step  F4A-3).  These  lists  are 
similar  to  those  used  in  Step  F4A-3,  except  that  they 
include  no  "already  scheduled"  tasks.  Each  list  may 
contain  'future  scheduled'  tasks  and  must  contain  at  least 
one  'currently  being  scheduled'  task.  The  corresponding 
list  of  labels  for  these  series  of  lists  was  formed  in 
P71  of  Step  F4A-2.  If,  for  one  of  the  various  reasons 
identified  in  Step  F4A-3,  it  was  found  necessary  in  that 
step  to  exclude  all  of  the  'already  scheduled'  tasks  from 
a  groups  of  tasks  being  processed  in  Step  F4A-3,  this 
group  of  tasks  would  then  be  processed  in  Step  F4A-4  (or 
Step  F4A-5,  if  there  was  only  one  task  remaining  on  the 
list  after  the  'already  scheduled'  tasks  had  been 
excluded).  This  means  that  Step  F4A-4  (and  F4A-5)  will  be 
working  from  lists  of  tasks  formed  in  either  Step  F4A-2  or 
Step  F4A-3. 

0  As  with  Step  F4A-3,  the  major  aim  of  the  Step  F4A-4 

scheduling  process  is  to  schedule  all  employee  transport 
tasks  for  a  given  employee  at  approximately  the  same  time. 
This  means  that  it  will  be  necessary  to  again  form 
scheduling  maps  (referred  to  as  P177  list  entry  groups  in 
Step  F4A-3)  in  Step  F4A-4.  These  scheduling  maps  define 
what  constitutes  "approximately  at  the  same  time".  The 
major  difference,  is  that  while  in  Step  F4A-3  these 
scheduling  maps  could  be  defined  at  the  beginning  of  the 
processing  by  defining  a  scheduling  map  to  begin  with  an 
already  scheduled  task  and  end  up  to  9  hours  later  (or 
when  the  next  already  scheduled  task  for  the  same  employee 
begins),  the  predefining  process  cannot  take  place  in  Step 
F4A-4.  This  is  because  tnere  are  no  already  scheduled 
tasks  to  use  to  predefine  scheduling  maps.  Instead,  such 
scheduling  maps  will  need  to  be  formed  whenever  a  search 


for  scheduling  options  begins  and  as  soon  after  the  first 
task  in  the  combination  of  task  scheduling  options  has 
been  tentatively  scheduled.  As  with  Step  F4A-3,  the 
process  of  defining  scheduling  maps  is  made  more  complex 
by  the  fact  that  not  all  tasks  in  a  given  group  will 
necessarily  be  such  that  they  can  be  performed  by  the  same 
person.  For  this  reason  (as  well  as  the  fact  that  the 
tasks  in  a  group  may  have  other  differing  characteristics 
such  as  different  preferred  time  uses),  it  is  not  possible 
to  simply  group  all  of  the  tasks  in  a  task  group  together 
and  schedule  them  as  though  they  were  one  task. 

Employee  transport  tasks  are  more  difficult  to  schedule 
than  other  tasks  in  which  employees  are  not  participants 
(i.e.,  employees  are  only  performers  of  the  task),  because 
it  is  necessary  to  ensure  that  the  tasks  for  the  same 
employee  are  not  scheduled  at  the  same  time.  In  Step 
F4A-3,  this  problem  was  more  easily  addressed  because  all 
of  the  already  scheduled  task  were  known  and  considered  in 
the  groups  of  tasks  being  scheduled.  Therefore,  when  one 
task  was  scheduled,  the  entire  calendar  time  for  that  task 
was  "blocked  off"  for  scheduling  for  other  tasks.  In  Step 
F4A-4  (and  Step  F4A-5)  there  are  either  no  'already 
scheduled'  tasks  (in  which  case  the  overlapping  of  tasks 
is  not  a  scheduling  problem)  or  the  already  scheduled 
tasks  have  been  removed  from  the  group  of  tasks  being 
scheduled,  in  which  case  it  is  necessary  to  check  before 
scheduling  a  task  in  a  time  slot  to  determine  that  this 
calendar  time  slot  is  not  already  scheduled  for  the  same 
employee.  It  should  be  noted  that  this  involves  not 
merely  checking  the  time  slot  on  the  monthly  schedule  data 
(0527)  which  is  being  used  to  attempt  to  schedule  the 
task.  It  also  requires  checking  the  same  calendar  time 
slots  in  al 1  sets  of  DS27  data  because  the  employee 
could  be  scheduled  for  a  task  in  the  same  calendar  time 
slot  but  the  person  performing  the  other  task  is  different 
from  the  task  tentatively  being  scheduled  (and  thus  would 
not  be  shown  on  the  DS27  data  being  scheduled  as  being 
tentatively  scheduled). 

In  Step  F4A-3,  Scheduling  Notices  (015)  were  not  sent  out 
after  the  tasks  were  scheduled,  because  the  employee 
participating  in  the  task  had  already  been  notified  of  the 
time  in  which  the  scheduling  of  the  task  was  scheduled  to 
begin,  when  the  'already  scheduled'  tasks  next  to  which 
the  tasks  in  the  groups  in  Step  F4A-3  are  being 
tentatively  scheduled  were  previously  scheduled.  In  Step 
F4A-4  (and  Step  F4A-5),  it  will  be  necessary  to  send 
Scneduling  Notices  (see  the  procedure  in  Step  F4A-6), 
because  the  scheduling  of  these  tasks  will  begin  at  a  time 
not  previously  scheduled  for  tasks  for  the  employee 
par t  i  c  ipat l ng  in  the  tasks. 
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PREVIOUS  STEP:  Step  F4A-4  follows  P77  of  Step  F4A-2  and  P1048  of 
Step  F4A-3. 
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In  this  Step,  single  employee  transport  tasks  (i.e.,  employee 
transport  tasks  for  which  there  are  no  'already  scheduled'  tasks  or 
'future  scheduled'  tasks  and  only  one  'currently  being  scheduled'  task 
for  the  same  employee)  are  scheduled.  The  processing  for  this  Step  is 
very  similar  to  that  of  Step  F4A-3  and  will  not,  therefore,  be 
repeated  here.  The  major  differences  between  Step  F4A-5  and  Step 
F4A-3  are  similar  to  those  differences  between  Step  F4A-4  and  Step 
F4A-3,  as  described  in  Step  F4A-4.  The  additional  differences  are: 

0  Step  F4A-5  uses  the  P24  list  formed  in  Steo  F4A-2  that 
contain  only  one  task.  The  "list"  containing  the  one 
label  for  this  one  task  in  this  "group"  of  tasks,  was 
formed  in  P68  in  Step  F4A-2. 

J  It  is  not  necessary  to  form  scheduling  maps  for  scheduling 

tasks  in  Step  F4A-5. 

Because  Step  F4A-5  is  the  last  Step  in  which  there  is  an 
opportunity  to  schedule  an  employee  transport  task,  one  of 
the  most  rigid  criteria  for  scheduling  tasks,  that  of 
scheduling  a  task  to  end  before  its  due  date  (if  any),  may 
have  to  be  waived  so  as  to  enable  scheduling  the  task  at 
all.  As  with  the  other  Steps  in  Function  F4A,  the  program 
“tries"  all  scheduling  options  that  have  scheduling  dates 
before  the  due  date  for  the  task  first,  and  only  resorts 
to  the  scheduling  of  a  task  after  its  due  date,  if  no 
other  scheduling  options  are  possible.  This  means  that 
other  less  than  ideal  scheduling  options  (such  as 
scheduling  the  task  in  a  time  use  that  is  not  the 
preferred  time  use)  will  be  attempted  first.  (Note:  This 
same  difference  in  the  scheduling  process  also  applies  to 
Step  F4A-7,  i.e.,  the  scheduling  processing  used  to 
schedule  single  non-employee  transport  tasks.) 


PREVIOUS  bTEP:  Step  F4A-5  follows  P78  of  Step  F4A-2,  P1050  of  Step 
F4m-3  and  the  equivalent  step  in  Step  F4A-4. 
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The  program  attempts  to  schedule  each  task  that  needs  to  be  scheduled 
(that  was  not  already  scheduled  in  Step  F4A-2,  i.e.,  that  is  not  an 
'employee  transport1  type  of  task).  In  this  Step  the  program  attempts 
to  schedule  the  task  "next  to"  (immediately  following)  other  already 
scheduled  tasks  that  are  similar  to  the  task  being  scheduled. 

The  program  is  organized  to  both  optimize  the  similarity  of  the  tasks 
next  to  which  as  task  is  scheduled  and  to  minimize  the  number  of 
interrupt  ions  in  the  scheduling  of  a  task.  The  order  of  preference 
for  determining  which  task  to  schedule  the  task  next  to  is  to  schedule 
the  task  next  to  (in  descending  order  of  preference): 

1)  A  task  that  will  be  conducted  in  the  same  facility  and 

involves  the  same  exact  requirement  implementation  unit(s) 
as  the  task  being  scheduled  and  requires  no  interrupt  ions , 
of  any  kind,  to  schedule  the  task. 

2)  A  task  that  will  be  conducted  in  the  same  facility  and 

has,  as  one  of  its  requirement  implementation  units,  the 
same  employee,  job  class  or  organizational  unit  as  the 
task  being  scheduled  and  requires  no  interruptions,  of  any 
kind,  to  schedule  the  task. 

3)  A  task  that  will  be  conducted  in  the  same  facility  and 

involves  no  interruptions,  of  any  kind,  to  schedule  the 
task . 

4)  A  task  that  will  be  conducted  in  the  same  facility  and 

involves  the  same  requirement  implementation  unit(s)  as 
the  task  being  scheduled;  and,  requires  no  interruptions, 
except  for  breaks  in  the  time  available  for  scheduling 
(i.e.,  no  interruptions  for  other  tasks,  other  time  uses, 
or  restrictions  on  the  scheduling  of  the  task;  the  only 
in  ►•-ruptions  are  for  breaks  in  the  time  that  the  person 
performing  the  task  has  available  for  any  type  of 
scheduling,  such  as  breaks  for  the  end  of  the  day,  for 
lunch,  etc.;  by  allowing  only  this  type  of  interruption  it 
is  ensured  that  the  task  will  not  be  interrupted  by  other 
tasks  (i.e.,  the  current  interrupt i ons  will  not  later  be 
filled  by  other  tasks),  because  no  tasks  can  be  scheduled 
luring  interruptions  for  breaks);  and,  requires  the 
smallest  number  of  such  break-type  of  interrupt  ions 
compared  to  other  tasks  that  arc  to  be  conducted  in  the 
same  facility  as  the  task  being  scheduled. 

5)  A  task  that  will  be  conducted  in  the  same  facility  ana 
has,  as  one  of  its  requirements  implementation  units,  the 
same  employee,  job  class  or  organ i zat iona 1  unit  as  the 
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task  being  scheduled;  requires  no  interrupt  ions ,  except 
for  breaks;  and  requires  the  smallest  number  of  such 
break-type  interruptions  (compared  to  other  tasks  that  are 
to  be  conducted  in  the  same  facility  as  the  task  being 
scheduled ) . 

6)  A  task  that  will  be  conducted  in  the  same  facility  and  has 
no  interrupt  ions  except  for  breaks  and  has  the  smallest 
number  of  these  interruptions  compared  to  other  tasks  that 
are  to  be  conducted  in  the  same  facility  as  the  task  being 
scheduled . 

7)  A  task  that  involves  the  same  requirement  implementation 
units  and  requires  no  interruptions,  of  any  kind,  ta 
schedule  the  task. 

8)  A  task  that  has,  as  one  of  its  requirement  implementation 
units,  the  same  employee,  job  class  or  organ  i  zat  i  _>n  unit 
as  the  task  being  scheduled  and  requ  ires  no  i n t e r  r up t i on s  , 
of  any  kind,  to  schedule  the  task. 

9)  A  task  that  involves  the  same  requirement  implementation 
unit(s)  and  requires  no  interruptions,  except  for  breaxs, 
and  requires  the  smallest  number  of  s_  o  ureas -type 
interruptions  compared  to  other  tasxs  involving  either  the 
same  requirement  implementation  unit  or  has,  as  one  or  its 
requirement  implementation  units,  the  same  employee,  job 
class  or  organizational  unit  as  the  task  being  scheduled. 

10}  A  task  that  has,  as  one  of  its  requirement  imp  1 ement at i on 
units,  the  same  employee,  job  class  or  organ izat ion  a!  unit 
as  the  task  being  scheduled  and  requires  no  interruptions, 
except  for  breaks,  and  requires  the  smallest  number  of 
sucn  interrupt  ions  compared  to  other  tasks  having,  as  one 
of  their  requirement  implementation  units,  the  same 
employee,  job  class  or  organizational  unit  as  the  task 
being  scheduled. 

The  program  logic  in  Step  F4A-6  identifies  all  of  the  options  for 
scheduling  a  task  next  to  a  similar  task  and  then  chooses  the  option 
with  the  highest  preference,  according  to  the  above  order  of 
preference. 

If  tnere  is  no  already  scheduled  task  that  is  similar  to  the  task 
being  scheduled,  or,  it  it  is  not  possible  to  schedule  the  task  next 
i,o  a  similar  task  without  resulting  in  interrupt  ions  (except  breaks), 
then  the  task  is  not  scheduled  next  to  a  similar  task,  i.e.,  it  is 
scheduled  in  the  earliest  available  time  slot  using  the  program  logic 
given  in  top  F4A-7. 

As  with  all  scheduling,  tne  program  checxS  to  ensure  that  the  task  is 
scheduled  to  hr-  completed  before  its  due  date  and  witnin  tne  time 
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slots  with  the  preferred  time  use  that  is  the  same  as  the  time  use 
required  for  the  task.  If  it  is  not  possible  to  schedule  the  task 
before  the  due  date  and  within  the  preferred  time  use  restrictions 
given  by  the  user,  while  being  scheduled  "next  to"  another  similar 
task,  then  attempts  to  schedule  the  task  next  to  other  similar  tasks 
are  abandoned,  i.e.,  being  scheduled  within  the  due  date  and  within 
the  preferred  time  use  takes  precedence  over  scheduling  the  task  next 
to  other  similar  tasks.  These  tasks  are  therefore  scheduled  in  Step 
F4A-4. 


PREVIOUS  STEP:  Step  F4A-6  follows  P 16  of  Step  F4A -2. 
INPUTS  (K  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 


Data  Retrieval s: 

HI:  The  list  of  task  identifiers  (ID23)  for  the 

non-employee  transport  type  of  tasks  that  currently 
need  to  be  scheduled;  from  the  list  generated  in  P12 
of  Step  F4A-2 

K2:  Current  date 

R3:  The  list  of  task  identifiers  (ID23)  for  the  tasks 

that  were  newly  determined  (i.e.,  determined  in  this 
execution  of  Function  F4A)  to  be  unscheduleable 
because  there  are  no  persons  qualified  to  perform  tne 
task  in  the  OHMIS  service  area  ( I D 10 )  in  which  the 
task  originated.  From  the  P5  list  from  Step  F4A-2. 

OS 23 :  Task  description  data 

OS 24 :  Specific  task  scheduling  data 

DS26:  Regular  weekly  schedule  availability  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

DL31:  List  of  task  identifiers  (ID23)  for  tasks  that  cannct 
be  scheduled  by  OHMIS  service  area  (  1 0 1 0 ) 

DL33:  List  of  monthly  schedule  identifiers  (ID27)  by  OHMIS 
service  area  ( I0IU ) 

UL34:  List  of  qualified  employee  identifiers  (1D4)  by  task 
type  C C T 8 )  and  by  OHMIS  service  area  (  I D 1 0 ) 

UL3t>:  List  of  requirement  implementation  units  (or  sets  of 
units)  linked  to  their  correspond  inq  task  identifier 
(Il)23),  OHMIS  service  area  identifier  (  I D 1 0 )  and 
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whether  the  task  is  an  'employee  transport'  type  of 
task 

0137:  List  of  the  task  identifier  (ID23)  by  the  main 

facility  identifier  ( ID8)  in  which  the  task  will  take 
place  and  by  its  OHMIS  service  area  (ID10) 

DL39:  List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  by  OHMIS  service  area  (1010) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) )  : 

PI:  Generate  a  copy  of  R1  list,  i.e.,  the  list  of  non-employee 

transport  type  of  tasks  that  are  to  be  scheduled  in  this 
execution  of  Function  F4A.  This  list  is  called  the  Pi 
list.  Retain  the  PI  list  throughout  Step  F4A-6. 

FN 1 :  FOR  each  of  the  task  identifiers  (1023)  on  the  PI  list: 

P2:  Locate  the  DS24  data  corresponding  to  the  ID23. 

P3:  Locate  the  task  type  code  (CT8)  on  the  DS24  data  from  P2. 

P 4:  Locate  the  DS23  data  corresponding  to  the  CT8  from  P3. 

P5;  Using  the  0323  data  from  P4,  determine  whether  this  is  a 
task  of  the  type  requiring  a  Scheduling  Notice  (015). 

P6:  Store  a  flag  to  indicate  what  type  of  iteration  of  Step 

F4A-3  processing  the  program  is  going  through.  This  will 
be  referred  to  as  the  P6  flag.  At  this  stage,  store  the 
flag  'A'  . 

P7:  Using  the  DS24  data  from  P2,  identify  the  OHMIS  service 

area  identifier  (1010),  the  requirement  implementation 
unit(s),  the  time  use  code  (CT11),  due  date  (if  any)  and 
the  user  specified  number  of  time  slots  required  to 
complete  the  task,  for  the  task  in  this  iteration  of  FN1. 

P8:  Using  the  DL34  list,  identify  the  employee  identif ier( s) 

(  IU4)  of  the  person(s)  qualified  to  perform  the  task  in 
this  iteration  of  FNl,  i.e.,  the  persons  qualified  to 
perform  the  tasks  with  the  task-type  code  (CT8)  identified 
in  P3  for  the  OHMIS  service  area  (1010)  from  P7.  Pul  on  a 
temporary  list  called  the  P8  list. 

P9:  Does  the  US24  data  from  P2  contain  a  facility  identifier 

( ID 8 ) ,  i.e.,  specify  the  location  in  which  the  task  is 
going  to  be  conducted?  Yes  =  P12;  No  =  P10 
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PIG:  Change  the  P6  flag  to  a  1 B ' . 

Pll :  GO  TO  P16 . 

P 12 :  Identify  the  108  from  the  DS24  data  from  P2. 

P 1 3 :  Are  there  any  task  identifiers  (ID23)  on  the  DL37  list  for 

the  same  ID10  as  that  identified  in  P7  and  the  same  ID8  as 
that  identified  in  P12  that  are  not  also  on  the  R3  list, 
i.e.,  any  tasks  that  are  going  to  be  conducted  in  the  same 
facility  as  the  task  in  this  iteration  of  FNl?  Yes  =  P14; 
No  =  P10 

P 14 :  Generate  a  temporary  list,  called  the  P14  list,  of  the 

I D 23 s  on  the  DL 37  list  that  have  the  same  ID10  and  ID8  as 

the  task  in  this  iteration  of  FNl  that  are  not  also  on 
the  R3  list. 

P15 :  GO  TO  P27 . 

Plo :  Are  there  any  task  identifiers  (ID23)  on  the  DL36  list 

which  have  the  same  set  of  requirement  implementation 
units  and  ID  10  as  the  requirement  implementation  unit(s) 
and  1010  for  the  task  in  this  iteration  of  FNl  (as 
determined  in  P 7 )  and  which  are  not  on  the  R3  list?  Yes 
=  P17;  No  =  P 19 

P17:  Generate  a  list,  called  the  P 1 7  list,  of  the  task 

identifiers  (1023)  on  the  0L36  list  that  have  the  same 
requirement  implementation  unit(s)  and  1010  as  the  task  in 
this  iteration  of  FNl  and  that  are  not  on  the  Re  list. 

P18:  GO  TO  P27 . 

P 19 :  Change  the  P6  flag  to  a  'C'. 

P20:  Do  the  requirement  implementation  unit(s)  for  the  task  in 

this  iteration  of  FNl  (as  determined  in  P 7 )  include  an 
employee  identifier  (1D4),  job  class  identifier  ( I D  7 )  or 
organizational  unit  identifier  ( IDl 2 ) ?  Yes  =  P24;  No  = 

P21 

P21:  Change  the  P6  flag  to  a  'O'. 

P22:  Add  the  ID23  for  this  iteration  of  FNl  to  a  list  called 

the  P22  list.  (Also  keep  this  ID23  on  the  Pi  list.) 

(Note:  Do  not  generate  a  new  P22  list  for  each  iteration 
of  FNl;  simply  add  the  1023  on  the  P22  list  that  was 
generated  in  the  first  iteration  of  FNl  in  which  substep 
P22  was  reached.) 


P23: 


Gu  TO  P1d3  (Next  FNl). 
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P24:  Identify  the  employee  identifier  (ID4),  job  class 

identifier  (ID7)  and/or  organizational  unit  identifier 
(ID12)  that  is  (are)  included  in  the  requirement 
implementation  unit(s)  for  the  task  in  this  iteration  of 
FNl  (as  determined  in  P7).  If  more  than  one  of  the 
requirement  implementation  units  are  ID4,  107  or  ID12 
types  of  identifiers,  put  the  entire  set  of  ID4,  ID7 
and/or  ID12  identifiers  on  a  list,  called  the  P24  list.) 

P25:  Are  there  any  task  identifiers  (ID23)  on  the  DL36  list 

that  have  the  same  employee  identifier  (ID4),  job  class 
identifier  (ID7)  or  organizational  unit  identifier  ( ID 1 2 ) 
as  that  identified  in  P24  (or  as  those  that  are  on  the  P24 
list)  and  that  are  not  on  the  R3  list?  Yes  =  P26;  No  = 

P21 

P26:  Put  the  task  identifiers  (ID23)  on  the  DL36  list  that  have 

the  same  ID4,  ID7  or  ID12  as  that  from  the  task  in  this 
iteration  of  FNl  and  that  are  not  on  the  R3  list  on  a 
temporary  list  called  the  P26  list. 

P 27 :  Identify  which  list  of  ID23s  to  use  in  FNl.l.  If  the  P6 

flag  is  an  'A1,  use  the  P14  list;  if  it  is  a  ’ B 1 ,  use  the 
P 1 7  list;  if  it  is  a  'C‘,  use  the  P26  list. 

FNl.l:  FOR  each  1023  on  the  list  identified  in  P27: 

P28:  Is  the  1023  also  on  the  PI  list,  i.e.,  one  of  the  task 

currently  being  scheduled?  Yes  =  P51  (next  FNl.l);  No  = 
P29 

P29:  Locate  the  DS24  data  correspond ing  to  the  ID23  for  this 

iteration  of  FNl.l;  locate  the  task  type  code  (CT8)  on 
this  DS24  data;  locate  the  0S23  data  corresponding  to  this 
CT8. 

P30:  Is  the  OS 23  data  from  P29  for  an  employee  transport  type 

of  task?  Yes  =  P51  (next  FNl.l);  No  =  P31 

P31:  Using  the  DS24  data  from  P29,  identify  the  requirement 

implementation  unit(s)  and  time  use  code  (CT11)  for  the 
task  in  this  iteration  of  FNl.l. 

P 32 :  Using  the  DS24  data  from  P29,  obtain  the  time  slot 

information  (i.e.,  the  monthly  schedule  identifier  (ID27) 
and  date  and  time  slot  number  (number  from  '1'  to  '96'  for 
the  quarter  of  an  hour  during  a  day))  for  the  end  time 
on  which  the  task  in  this  iteration  of  FNl.l  is  scheduled 
to  be  completed. 
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Is  the  end  time  slot  identified  in  P32  before  the 
current  date  ( R 2) ?  Yes  =  P51  (next  FNl.l);  No  =  P34 

Is  there  a  due  date  on  the  0S24  data  from  P2  (as 
determined  in  P 7 ) ?  Yes  =  P 35 ;  No  =  P36 

Is  the  due  date  for  the  task  in  this  iteration  of  FNl  (as 
determined  in  P 7 )  equal  to  or  earlier  than  the  data  for 
which  the  task  in  this  iteration  of  FN1.1  is  scheduled  to 
end  (i.e.,  the  end  time  for  the  scheduling  of  this  task 
as  determined  in  P 32 ) ?  Yes  =  P36;  No  =  P5i  (next  FN 1.1) 

Locate  the  0S27  data  corresponding  to  the  monthly  schedule 
identifier  (1027)  that  is  contained  in  the  end  time  slot 
information  for  the  task  in  this  iteration  of  FNl.l  (as 
determined  in  P32),  Locate  the  employee  identifier  (104) 
on  this  DS27  data,  i.e.,  the  person  to  scheduled  to 
perform  the  tasks  on  this  DS27  data. 

Is  the  104  identified  in  P36  one  of  the  ID4s  on  the  P8 
list?  Yes  =  P38;  No  =  P51  (next  FNl.l) 

Is  the  P6  flag  a  'A',  ' B 1  or  'C'?  (Note:  It  cannot  be  a 
'D',  because  the  program  would  not  have  reached  P38,  if  it 
were.)  A  =  P39;  8  =  P48;  C  =  P50 

Are  the  requirement  implementation  units  for  the  task  in 
this  iteration  of  FNl.l  (as  determined  in  P31)  the  same  as 
those  for  the  task  in  this  iteration  of  FNl  (as  determined 
in  P 7) ?  Yes  =  P 40 ;  No  =  P42 

Put  the  ID23  for  this  iteration  of  FNl.l  on  a  temporary 
list  called  the  P40  list.  The  P40  list  is  a  list  of 
already  scheduled  tasks  that  are  scheduled  for  the  same 
facility  and  requirement  implementation  unit(s)  as  the 
task  in  this  iteration  of  FNl  and  which  are  scheduled  in 
a  time  slot  next  to  which  it  is  acceptable  to  schedule  the 
task  in  this  iteration  of  FNl. 

GO  TO  P51  (next  FNl.l). 

Do  the  requirement  implementation  units  for  the  task  for 
this  iteration  of  FNl  (as  determined  in  P 7 )  include  an 
employee  identifier  ( ID 4 ) ,  job  class  identifier  ( ID 7 )  or 
organizat ional  unit  identifier  ( ID12 ) ?  Yes  =  P45;  No  = 

P43 


Put  the  ID23  for  this  iteration  of  FNl.l  on  a  temporary 
list  called  the  P43  list;  the  P43  list  is  a  list  of 
already  scheduled  tasks  that  are  scheduled  for  the  same 
facility  as  the  task  in  this  iteration  of  FNl  and  which 
are  scheduled  in  a  time  slot  next  to  which  it  is 
acceptable  to  schedule  the  task  in  this  iteration  of  FNl, 


i  — 
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GO  TO  P51  (next  FNl.l). 


Is  the  employee  identifier  (104),  job  class  identifier 
( ID  7 )  or  organizational  unit  identifier  (1012)  that  is 
included  in  the  requirement  implementation  units  for  the 
task  in  this  iteration  of  FNl  (as  determined  in  P7)  also 
one  of  the  requirement  implementation  units  on  the  task  of 
this  iteration  of  FNl.l  (as  determined  in  P31)?  Yes  = 

P46;  No  =  P43 

Put  the  ID23  for  th  s  iteration  of  FNl.l  on  a  temporary 
list  called  the  P46  list.  The  P46  list  is  the  list  of 
already  scheduled  tasks  that  are  scheduled  for  the  same 
facility  and  employee,  job  class  or  organizational  unit  as 
the  task  in  this  iteration  of  FNl  and  which  are  scheduled 
in  a  time  slot  next  to  which  it  is  acceptable  to  schedule 
the  task  in  this  iteration  of  FNl. 

GO  TO  P51  (next  FNl.l). 

Put  the  1023  for  this  iteration  of  FNl.l  on  a  temporary 
list  called  the  P48  list.  The  P48  list  is  the  list  of 
already  scheduled  tasks  that  are  scheduled  for  the  same 
requirement  implementation  unit(s)  as  the  task  in  this 
iteration  of  F N 1  and  which  are  scheduled  in  a  time  slot 
next  to  which  it  is  acceptable  to  schedule  the  task  in 
this  iteration  of  FNl. 

GO  TO  P51  (next  FNl.l). 

Put  the  1023  for  this  iteration  for  FNl.l  on  a  temporary 
list  called  the  P50  list.  The  P50  list  is  the  list  of 
already  scheduled  tasks  that  are  scheduled  for  the  same 
employee,  job  class  or  organizational  unit  as  the  task  in 
This  iteration  of  FNl  and  which  are  scheduled  in  a  time 
slot  next  to  which  it  is  acceptable  to  schedule  the  task 
in  this  iteration  of  FNl. 


P51: 

NEXT  FNl.l;  end  of  FNl.l,  GO  TO 

P52 . 

P52 : 

Is  the  P6  flag  an  'A'?  Yes  =  P53;  No 

=  P60 

P53 : 

Are  there  any  1023s  on  the  P40 

list? 

Yes  = 

P54; 

No  =  P56 

P54 : 

Change  the  P6  flag  to  an  ' A1 ' . 

P55  : 

GO  TO  P60 . 

P56 : 

Are  there  any  1023s  on  the  P46 

list? 

Yes  = 

P57 ; 

No  =  P59 

P57 : 

Change  the  P6  flag  to  an  ’A21. 

( - 
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P58:  Are  there  any  ID23s  on  the  P43  list?  Yes  =  P59;  No  =  P60 

P59:  Change  the  P6  flag  to  an  'A3'. 

P60:  Determine  which  list  to  use  in  FN 1.2.  If  the  P6  flag  is 

an  'Al1,  use  the  P40  list;  if  an  ' A2 1 ,  use  the  P46  list; 
if  an  'A3',  use  the  P43  list;  if  a  * B 1 ,  use  the  P48  list; 
if  a  'C' ,  use  the  P50  list. 

FN1.2:  FOR  each  ID23  on  the  list  identified  in  P60: 

P61 :  Locate  the  DS24  data  for  the  ID23. 

P62:  Using  the  DS24  data  from  P61,  identify  the  time  slot 

information  (i.e.,  the  monthly  schedule  identifier  (ID27), 
date  (1-31)  and  time  slot  number  (a  number  from  *1'  to 
* 96 *  indicating  the  quarter  of  an  hour  period  in  a  day)) 
for  the  end  time  of  the  scheduling  of  the  task  in  this 
iteration  of  FNl.2. 

P63:  Put  the  ID27  identified  as  a  part  of  the  time  slot 

information  for  the  end  time  identified  in  P62  on  a 
temporary  list  called  the  P63  list. 

P64:  Locate  the  DS27  data  corresponding  to  the  ID27  identified 

as  a  part  of  the  time  slot  information  for  the  end  time 
identified  in  P62.  Identify  the  employee  identifier  ( ID4) 
of  the  person  for  whom  this  set  of  DS27  data  is  a  monthly 
schedule  and  the  year  and  month  covered  by  this  set  of 
D327  data. 

FNl.2.1:  FOR  each  ID27  on  the  DL33  list: 

P6b:  Is  the  ID27  the  same  as  the  ID27  identified  in  P62?  Yes  = 

P71  (next  FNl.2.1);  No  =  P66 

P66:  Locate  the  DS27  data  for  the  ID27  in  this  iteration  of 

FNl.2.1.  Is  this  DS27  data  for  the  same  OHMIS  service 
area  ( 1010 )  as  the  task  in  this  iteration  of  FNl  (as 
determined  in  P 7) ?  Yes  =  P67;  No  =  P71  (next  FNl.2.1) 

P67:  Using  the  DS27  data  located  in  P66,  identify  the  employee 

identifier  (ID4)  of  the  person  for  whom  this  is  a  schedule 
and  the  year  and  month  covered  by  this  schedule. 

P6d:  Is  the  DS27  data  from  P6b  for  the  same  employee  identifier 

( I L) 4 )  as  that  identified  in  P66?  Yes  =  P69;  No  =  P71 
(next  FNl.2.1) 

P69:  Is  the  DS 27  data  from  P66  for  a  year  and  month  that  is 

later  than  tne  year  and  month  of  the  DS27  data  from  P64? 
Yes  =  P7U;  No  =  P71  (next  FNl.2.1) 
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P 70 :  Put  the  1027  for  this  iteration  of  FN 1 .2.1  on  the  P63 
list. 

P71 ;  NEXT  FNl.2.1;  end  of  FNl.2.1,  GO  TO  P72. 

P 72 :  Using  the  corresponding  DS27  data,  put  the  1027s  on  the 

P63  list  in  order  of  ascending  year  and  month.  This 
ordered  list  is  called  the  P72  list. 

P73:  Start  a  counter,  called  the  P73  counter,  with  the  value 

'O'  in  it.  This  counter  will  be  the  count  of  the  number 
of  time  slots  tentatively  scheduled  for  the  task  in  this 
i teration  of  FNl. 

P74:  Start  a  counter,  called  tne  P74  counter,  with  the  value 

'0'  in  it.  This  counter  vill  be  the  count  of  the  number 
of  time  slots  tentatively  scheduled  for  the  task  since 
the  last  interruption. 

P75:  Start  a  counter,  called  the  P75  counter,  with  the  value 

'O'.  This  will  be  a  counter  of  the  number  of 
interruptions  in  the  scheduling  of  the  task  in  this 
iteration  of  FNl  as  it  is  tentatively  scheduled. 

FNl. 2. 2:  FOR  each  1027  on  the  P72  list: 

P76:  Locate  the  D527  data  for  this  ID27. 

FNl .2. 2.1:  FOR  each  day  (1-31)  on  the  DS27  data  from  P 76 : 

P77:  Is  this  date  equal  to  or  later  than  the  end  date  for  which 

the  task  in  this  iteration  of  FNl. 2  is  scheduled  to  be 
completed  (as  determined  in  P62 ) ?  Yes  =  P78;  No  =  P107 
( next  FNl . 2. 2. 1) 

P 78 :  Does  the  task  in  this  iteration  of  FNl  have  a  due  date  (as 

determined  in  P 7 ) ?  Yes  =  P79;  No  =  P80 

P 79 :  Is  the  day  in  this  iteration  of  FNl. 2. 2.1  later  than  the 

due  date  for  the  task  in  this  iteration  of  FNl  (as 
determined  in  P 7 ) ?  Yes  =  P15  (next  FNl. 2);  No  =  P80 

P80:  Is  the  day  in  this  iteration  of  FNl. 2. 2.1  equal  to  one  of 

the  days  specified  on  the  DS24  data  from  P2  as  being  a 
restricted  day  (i.e.,  a  day  on  which  the  task  in  this 
iteration  of  FNl  cannot  be  scheduled)?  Yes  =  P107  (next 
FNl. 2. 2.1);  No  =  P81 

P81 :  Does  the  DS24  data  from  P2  have  a  weekly  schedule 

identifier  (1028)  specified  on  it,  i.e.,  an  identifier 
identifying  the  0S2b  data  which  gives  the  standard 
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restricted  times  and  days  of  the  week  for  this  task  (i.e., 
the  standard  times  of  a  week  that  this  task  cannot  be 
scheduled)?  Yes  =  P82;  No  =  FNl. 2.2.1. 1  ( P 85 ) 

P82:  Locate  the  DS26  data  for  the  ID28  on  the  DS24  data  from 

P2. 

P83:  Locate  the  day  of  the  week  on  the  DS26  data  from  P82  that 

is  the  same  as  the  day  of  the  week  for  this  iteration  of 
FNl. 2. 2.1.  (The  DS27  data  from  P76  will  indicate  the  day 
of  the  week  for  each  day  on  the  monthly  schedule,  i.e., 
the  day  of  the  week  for  this  iteration  of  FNl. 2. 2.1.) 

P84:  Ooes  the  DS26  data  from  P82  indicate  that  the  entire  day 

of  the  week  identified  in  P59  is  a  restricted  day?  Yes  = 
P107  (next  FNl. 2. 2.1);  No  =  FNl. 2. 2. 1.1  (P85) 

FNl. 2. 2. 1.1:  FOR  each  time  slot  number  (i.e.,  number  from  '1' 

to  '96'  representing  the  quarter  of  an  hour  time  periods 
in  a  day)  for  the  day  in  this  iteration  of  FNl. 2. 2.1: 

P8b:  Is  this  time  slot  later  than  the  time  slot  identified  as 

the  end  time  for  the  task  in  this  iteration  of  FNl. 2  (as 
determined  in  P62)?  Yes  =  P86;  No  =  P1U6  (next 
FNl. 2. 2. 1.1) 

P86:  According  to  the  0S27  data  from  P76,  is  this  time  slot 

(i.e.,  tne  time  slot  for  this  iteration  of  FNl. 2. 2. 1.1) 
available  for  scheduling?  Yes  =  P87;  No  (i.e.,  if  the 
time  slot  in  this  iteration  of  FNl. 2. 2. 1.1  is  chosen  for 
scheduling  the  task  in  FNl,  the  scheduling  will  include 
interruptions  in  the  time  set  aside  for  scheduling  this 
task)  =  P99 

P87:  According  to  the  DS 27  data  from  P76,  is  the  preferred  time 

use  code  (CT11)  for  the  time  slot  in  this  iteration  of 
FNl. 2. 2. 1.1  the  same  as  tne  CT11  for  the  task  in  this 
iteration  of  FNl  (as  determined  in  P 7) ?  Yes  -  P88 ;  No 
(i.e.,  tnere  is  an  interruption  in  the  time  for  scheduling 
the  task  in  this  iteration  of  FNl  if  this  task  is  to  be 
scheduled  next  to  the  task  in  this  iteration  of  FNl. 2; 
this  interruption  is  not  a  break;  this  interruption  is 
such  that  the  time  slot  in  this  iteration  of  FNl. 2. 2. 1.1 
(the  interruption)  could  at  the  present  time  or  at  a  later 
date  be  filled  with  another  task,  i.e.,  a  task  different 
from  the  task  in  this  iteration  of  FNl;  therefore,  it  is 
not  desirable  to  schedule  the  task  in  this  iteration  of 
FNl  next  to  the  task  in  this  iteration  of  FNl. 2,  because 
it  is  not  desirable  to  have  a  task  scheduled  so  as  to  have 
the  potential  for  being  interrupted  by  other  tasks)  =  P 1 1 4 
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P 88 :  Does  the  0S24  data  from  P2  contain  an  JD28  for  a  set  of 

DS26  data  indicating  time  restriction  for  the  task?  Yes  = 
P89;  No  =  P92 

P89:  Locate  the  0S26  data  for  the  ID28  on  the  DS24  data  from 

P2. 

P90:  Locate  the  day  of  the  week  and  time  slot  number  on  the 

DS26  data  from  P89  corresponding  to  the  oay  of  the  week 
for  this  iteration  of  FNl.2.2.1  and  the  time  slot  for  this 
iteration  of  FNl.2.2.1.1. 

P91:  Does  the  0S26  data  from  P89  indicate  that  the  time  slot 

identified  in  P90  is  a  restricted  time  slot,  i.e.,  cannot 
be  used  to  schedule  the  task  in  this  iteration  of  FN1? 

Yes  (i.e.,  there  is  an  interruption  in  the  time  for 
scheduling  the  task  in  this  iteration  of  FnI  if  the  task 
is  to  be  scheduled  next  to  the  task  in  this  iteration  of 
FN1.2;  this  interruption  is  not  a  break ;  this  interruption 
is  the  type  the  time  slot  in  this  iteration  of  FNl.2.2.1.1 
(i.e.,  the  interruption)  could  at  the  present  time  or  at  a 
later  date  be  filled  with  another  task,  i.e.,  a  task  other 
than  the  task  in  this  iteration  of  FNl;  therefore,  it  is 
not  desirable  to  schedule  the  task  in  this  iteration  of 
FNl  next  to  the  task  in  this  iteration  of  FNl. 2,  because 
it  is  not  desirable  to  have  tasks  scheduled  so  as  to  have 
the  potential  for  being  interrupter  by  other  tasks)  = 

P 1 1 4 ;  No  =  P92 

P92:  According  to  the  OS27  data  from  P76,  is  there  a  task 

already  scheduled  for  the  time  slot  in  this  iteration  of 
FNl.2.2.1.1,  i.e.,  a  task  identifier  (1023)  in  this  time 
slot  on  the  DS27  data?  Yes  (i.e.,  there  is  an 
interruption  in  the  time  available  for  scheduling  the  task 
in  this  iteration  of  FNl  if  this  task  is  to  be  scheduled 
next  to  the  task  in  this  iteration  of  FNl. 2  because  of 
another  task  being  scheduled,  i.e.,  a  task  different  than 
the  task  in  this  iteration  of  FNl;  therefore,  it  is  not 
desirable  to  schedule  the  task  in  this  iteration  of  FNl 
next  to  the  task  in  this  iteration  of  FNl. 2)  =  P 1 1 4 ;  No 
(i.e.,  it  is  possible  to  tentatively  schedule  the  task  in 
this  iteration  of  FNl  in  the  time  slot  in  this  iteration 

of  FNl. 2. 2. 1.2  as  part  of  scheduling  this  task  next  to  the 

task  in  this  iteration  of  FnI. 2)  =  P93 

P93:  Add  '1'  to  the  counter  in  P73  (total  time  slots 

tentatively  scheduled). 

P94:  Add  '1'  to  the  counter  in  P74  (total  time  slots 

tentatively  scheduled  since  the  last  interruption). 
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P9b:  Generate  a  flag  indicating  that  the  last  time  slot  was 

tentatively  scheduled.  (Note:  This  will  be  used  to  tell 
the  program  whether  the  next  time  slot  that  is  an 
interruption  is  the  beginning  of  an  interruption  (if  there 
is  a  P95  flag)  or  a  continuation  of  an  interruption  (if 
there  is  no  P95  flag)). 

P96:  Generate  or  add  to  a  list  called  the  P96  list.  Add  one 

set  of  the  following  data  elements  to  the  list: 

(1)  The  time  slot  information  for  this  iteration  of 
FNl.2.2.1.1.  The  time  slot  information  is  the  ID27 
in  this  iteration  of  FNl.2.2,  the  day  (1-31)  in  this 
iteration  of  FNl. 2. 2.1  and  the  time  slot  number 
(1-96)  in  this  iteration  of  FNl.2.2.1.1. 

(2)  The  value  in  the  P73  counter  as  of  this  iteration 
of  FNl.2.2.1.1. 

(3)  The  value  in  the  P74  counter  as  of  this  iteration 
of  FNl.2.2.1.1. 

(4)  The  value  in  the  P75  counter  as  of  this  iteration 
of  FNl.2.2.1.1. 

P97:  Identify  the  user  specified  number  of  time  slots 

required  to  complete  the  task  in  this  iteration  of  FN1  (as 
determined  in  P 7 )  and  add  the  number  in  the  P 75  counter 
(number  of  interrupt  ions )  to  it.  (Note:  Each 
interruption  adds  one  time  slot  to  the  time  slots  required 
to  complete  a  task.) 

P98:  Is  the  value  in  the  P73  counter  (number  of  time  slots 

tentatively  scheduled)  equal  to  the  value  derived  in  P97? 
Yes  (i.e.,  enough  available  time  slots  have  been  found  to 
schedule  tne  task  in  this  iteration  of  FN1  next  to  the 
task  in  this  iteration  of  FNl.2,  i.e.,  the  time  slots 
tentatively  scheduled  for  the  task  in  this  iteration  of 
FNl  equal  the  time  slots  required  to  complete  the  task 
plus  the  extra  time  slots  allowed  for  interruptions)  = 
P109;  No  =  P106  (next  FNl.2.2.1.1) 

P99:  (From  P86.)  Is  there  a  P96  flag  (i.e.,  was  the  last  time 

slot  tentatively  scheduled)?  Yes  (i.e.,  the  time  slot  in 
this  iteration  of  FNl.2.2.1.1  is  the  first  time  slot  in 
this  interruption  of  the  scheduling  of  the  task  in  this 
iteration  of  FNl)  =  PlUO;  No  (i.e.,  this  time  slot  is  a 
continuation  of  an  interruption)  =  P 1 1 5  (next  FNl.2.2.1.1) 


PlUU:  Erase  the  P95  flag. 


PlUl:  Is  the  P74  counter  (number  of  time  slots  tentatively 

scheduled  since  last  interruption)  equal  to  'O';  *1'  or 
'2';  or  'greater  than  2'?  'O'  (i.e.,  no  time  slots  have 

yet  been  tentatively  scheduled  for  the  task  in  this 
iteration  of  FNl  that  are  next  to  the  task  in  this 
iteration  of  Fn*.2,  because  the  first  time  slot  next  to 
the  task  in  this  iteration  of  FNl. 2  was  not  available  for 
scheduling,  i.e.,  was  a  break )  =  P102;  ' 1 ‘  or  '2'  (i.e., 
less  than  three  time  slots  have  been  tentatively  scheduled 
since  the  last  interruption;  this  is  too  few  time  slots  to 
schedule  before  an  interruption ;  therefore,  it  is  not 
possible  to  schedule  the  task  in  this  iteration  of  FNl 
next  to  the  task  in  this  iteration  of  FNl. 2)  =  P 1 1 4 ; 
‘greater  than  2'  =  P1U4 

P1G2:  Add  '1'  to  the  P 7b  counter  (number  of  interruptions). 

P 10 3 :  GO  TO  P106  (next  FNl . 2. 2. 1 . 1 ) . 

P 104 :  Identify  the  number  of  user  specified  time  slots 

required  to  complete  the  task  in  this  iteration  of  FNl  (as 
determined  from  P7)  and  add  the  number  in  the  P75  counter 
(number  of  interrupt  ions)  to  it.  (Note:  Each 
interruption  adds  one  time  slot  to  the  time  required  to 
complete  a  task  . ) 

P105 :  Subtract  the  value  currently  in  the  P73  counter  ( number  of 
time  slots  tentatively  scheduled)  from  the  value  derived 
in  P 10 4 .  Is  the  remainder  less  than  '3'?  Yes  (i.e., 
there  is  less  than  three  time  slots  left  to  schedule  for 
this  task  and  there  has  been  an  interruption;  this  is  too 
few  time  slots  to  schedule  after  an  interruption; 
therefore,  it  is  not  possible  to  schedule  the  task  in  this 
iteration  of  FNl  next  to  the  task  in  this  iteration  of 
FNl. 2)  =  P 1 1 4 ;  No  =  P102 

PI 06 :  NEXT  CN1 . 2. 2 . 1 . 1 ;  end  of  FNl. 2. 2. 1.1,  GO  TO  P107. 


PI 07 :  NEXT  FNl. 2. 2.1;  end  of  FNl. 2. 2.1,  GO  TO  P108. 


P10G:  NEXT  FNl. 2.2;  end  of  Fn1.2.2,  GO  TO  P114. 


P1U9:  (From  P98,  i.e.,  from  the  point  at  which  it  was  determined 

that  enough  time  slots  have  been  tentatively  scheduled  to 
fully  schedule  the  task  in  this  iteration  of  FNl  next  to 
the  task  in  this  iteration  of  FNl. 2.)  Generate  a 
temporary  record,  called  the  P 109  temporary  record.  Put 
two  items  on  this  record: 


(1)  The  task  identifier  (1023)  in  this  iteration  of 
FNl. 2  (this  is  the  label  for  the  record ) ;  and, 
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(2)  The  entries  (i.e.,  the  sets  of  four  data  elements) 
on  the  P96  list  (i.e.,  the  tentative  schedule). 

Retain  a  separate  P1U9  record  for  each  iteration  of 
FNl. 2  in  which  Step  P109  is  executed,  i.e.,  do  not  replace 
the  old  P 109  record,  but  add  a  new  P 109  record  throughout 
the  iterations  of  FNl.  The  P 109  record  is  called  an 
"option  record",  because  it  provides  one  option  for 
scheduling  the  task  in  this  iteration  of  FNl. 2.  If  it  is 
not  possible  to  schedule  the  task  without  any 
interruptions,  the  options  in  the  Piu9  records  will  be 
reviewed  to  select  the  scheduling  option  with  the  least 
number  of  interruptions  (see  FNl. 3). 

P110:  Start  a  temporary  list,  called  the  P 1 10  list,  of  the 
labels  (1023s)  for  the  P109  records;  or,  if  P 1 10  has 
already  been  reached  previously,  add  to  tne  existing  P 1 1 0 
list.  Leave  space  next  to  each  entry  ( 1023 )  on  this  list 
for  a  flag  indicating  that  this  is  the  P109  record  tnat 
should  be  used  for  scheduling.  Put  the  1023  used  to  label 
the  P109  record  generated  in  this  iteration  of  FNl. 2, 
i.e.,  tne  P 109  record  generated  in  the  last  execution  of 
P1U9,  on  the  bottom  (end)  of  the  Pill)  list.  The  order  of 
the  P 110  list  is  important.  It  should  be  in  the  same 
order  as  the  order  in  which  the  P 109  records  were 
generated,  i.e.,  the  tasks  associated  with  a  P6  flag  of 
' A 1 1  should  come  first,  then  the  tasks  associated  with  a 
P6  flag  of  'A2',  then  'A31;  or,  the  task  associated  with  a 
P6  flag  of  1 B '  and  then  the  task  associated  with  a  P6  flag 
or  'C‘.  This  order  ensures  that  the  option  records  chosen 
for  scheduling  (i.e.,  the  FNl. 2  task  next  to  which  the 
task  in  this  iteration  of  FNl  is  to  be  scheduled)  is  the 
one  most  si"1  ar  to  the  task  in  this  iteration  of  FNl. 

Pill:  Is  the  value  currently  in  the  P 75  counter  (number  of 

interruptions)  equal  to  'O'?  Yes  (i.e.,  the  current 
tentative  scheduling  of  the  task  is  the  one  that  should  be 
used;  that  is  the  task  in  this  iteration  of  FNl  should  be 
scheduled  next  to  the  task  in  this  iteration  of  FNl. 2)  5 
P112;  No  (i.e.,  the  program  continues  to  look  for  other 
tasks  to  schedule  the  task  in  this  iteration  of  FNl  next 
to  in  order  to  find  tasks  that  are  better,  i.e.,  tasks 
that  do  not  require  any  interruptions  to  schedule  the  task 
in  this  iteration  of  FNl  next  to  them)  =  P 11 4 

P112:  Flag  the  last  1023  on  the  P 1 10  list  (i.e.,  fill  in  the 
blank  space  next  to  the  1023)  as  the  ID23  that  is  the 
label  for  the  P 109  record  that  is  to  be  used  to  schedule 
the  task  in  this  iteration  of  FNl. 


P113:  GO  10  P 1 3b . 
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P 1 1 4 :  Erase  the  P96  list,  if  any. 

P 1 1 5 :  NEXT  FNl.2;  end  of  FNl.2,  GO  TO  P116. 


P 1 1 6 :  Is  the  P6  flag  an  ‘A1‘,  'A2\  'A3‘,  ' B ' ,  or  a  'C'?  A1  = 
P56 ;  A2  =  P58;  A3  =  P119;  B  =  P117;  C  =  P119 

P 1 1 7 ;  Change  the  P6  flag  to  a  ‘C1. 

P 1 1 8 :  GO  TO  P 60. 

P119:  Are  there  any  1023s  on  the  P 1 1 0  list?  That  is,  are  there 
any  P109  records,  i.e..  any  records  giving  options  for 
scheduling  the  task  in  this  iteration  of  FNl  next  to  the 
task  in  this  iteration  of  FNl.2  where  the  option  would 
allow  for  scheduling  tne  task  next  to  a  task  that  is  at 
least  in  the  same  facility  and  may  also  involve  the  same 
requirement  implementation  units  or  employee,  job  class  or 
organizational  unit  as  Pu-  ms*.  in  this  iteration  of  FNl? 
Yes  =  P123;  No  =  PisO 

P120:  Is  the  P6  flag  an  'A3'  or  a  1 ^ 1 ?  A3  l  i.e.,  there  are  no 
options  for  scheduling  the  tas*.  in  this  iteration  of  FNl 
next  to  a  task  that  is  t'  be  conducted  in  the  same 
facility  as  the  task  in  this  iteration  of  FNl)  =  P121;  C 
(i.e.,  there  are  no  options  for  scheduling  the  task  in 
this  iteration  of  FNl  next  to  a  task  tnat  has  tne  same 
employee,  job  class  or  organizational  unit  as  a 
requirement  implementation  unit  as  the  task  in  this 
iteration  of  FNl;  that  is,  there  are  no  options  for 
scheduling  the  task  in  FNl  next  to  any  similar  task)  =  P22 

P 121 :  Change  the  P6  flag  to  a  ’B1. 

P 1 2 2 :  GO  TO  P60. 

FNl. 3:  FOR  each  of  the  1023s  on  the  P 1 1 0  list: 

P 1 2 3 :  Locate  the  P109  record  for  this  1023. 

P124:  Examine  the  last  entry  (i.e.,  tne  last  set.  of  t  njr  data 
elements)  on  the  P109  record  from  P123.  Ideuti*>  tn>- 
value  for  the  fourth  data  element  on  this  enf> .  '•  :- 

identify  the  value  in  the  3  7b  count'"'  i.ou 
interruptions  at  the  time  that  Mm  r*  *  •••  •  *  . 

tentatively  scheduled.  Is  t.hi  n'  ,■  ■.  '  .  ' 

the  scheduling  option  in  tn,.  r  1  u  •  .  .  .. 

iteration  of  FNl.  3  has  M.  1  • 

int-rrup'  lair,;  to . •  >•.  .  ‘  • 


recommended  system  design  for  the  occupational  health 
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P125 : 

P126: 

P127: 

P128: 

P129: 

P130: 

P131: 

P132: 

P133: 
P134: 
P135 : 

P136: 

P137: 

P138: 


Place  a  flag  in  the  space  on  the  PllO  list  next  to  the 
1023  in  this  iteration  of  FN1.3.  The  P109  record  labeled 
with  this  ID23  is  to  be  used  for  scheduling  the  task  in 
this  iteration  of  FN1. 

GO  TO  P136. 

Is  the  P109  record  in  this  iteration  of  FNl.3  the  first 
P109  record  on  the  list?  Yes  =  P128;  No  =  P13I 

Store  the  value  identified  in  P124  (i.e.,  store  the  number 
of  interruptions  in  the  scheduling  option  given  on  the 
P109  record  for  this  iteration  of  FN1.3). 

Store  the  ID123  for  this  iteration  of  FNl.3. 

GO  TO  P134  (next  FNl.3). 

Is  the  value  identified  in  P124  less  than  the  value  stored 
in  P129?  Yes  =  P132;  No  =  P134  (next  FNl.3) 

Change  the  value  stored  in  P128  to  the  value  identified  in 
P124. 

Change  the  1023  stored  in  P129  to  the  1023  for  this 
iteration  of  FNl.3. 

NEXT  FNl.3;  end  of  FNl.3,  GO  TO  P135. 

Place  a  flag  on  the  PllO  list  next  to  the  ID23  that  is  the 
same  as  the  ID23  stored  in  P129.  The  P109  record  labeled 
with  this  ID23  is  to  be  used  for  scheduling  the  task  in 
this  iteration  of  FNl. 

Identify  the  ID23  on  the  PllO  list  with  a  flag  in  it 
indicating  that  this  is  the  task  next  to  which  the  task  in 
this  iteration  of  FNl  is  to  be  scheduled. 

Locate  the  P109  record  for  the  ID23  from  P136.  This  is 
referred  to  as  the  P137  record.  Erase  the  other  P109 
records,  if  any. 

Begin  to  enter  the  scheduling  information  for  the  task  in 
this  iteration  of  FNl  onto  the  OHMIS  data  base.  First, 
complete  the  DS24  data  for  the  task  (i.e.,  the  DS24  data 
identified  in  P 2) .  Answer  the  question  of  whether  the 
user  specified  the  schedule  as  'No'.  Answer  the  question 
of  whether  it  was  possible  to  schedule  the  task  with  a 
'Yes'.  (Change  this  answer  from  its  previous  'No'  and 
remove  the  code  explaining  why  the  task  had  not  been 
scheduled.)  For  the  start  time  of  the  task  use  the 
first  set  of  time  slot  information  (i.e.,  the  ID27,  date 
( 1-31 )  and  time  slot  number  (1-96))  on  the  P137  record. 
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For  the  end  time  use  the  last  set  of  time  slot 
information  on  the  P137  record.  Place  the  value  in  the 
second  data  element  in  the  last  set  of  time  slot 
information  on  the  P137  record  (i.e.,  the  value  from  the 
P73  counter  (number  of  time  slots  scheduled)  as  the  total 
number  of  actual  time  slots  scheduled  for  the  task. 

Place  the  value  for  the  fourth  data  element  in  the  last 
set  of  time  slot  information  on  the  P137  record  (i.e.,  the 
value  for  the  P75  counter  (number  of  interruptions)  as  of 
the  last  time  slot  scheduled  for  the  task)  as  the  total 
number  of  interruptions  in  the  scheduling  of  the  task. 
Answer  the  question  about  whether  the  task  is  scheduled  to 
be  completed  after  its  due  date  as  'No*.  Answer  the 
question  about  whether  it  was  possible  to  schedule  the 
task  during  the  preferred  time  use  as  ’Yes'. 

P139:  Is  the  task  identifier  (ID23)  for  this  iteration  of  FNl  on 
the  DL31  list?  Yes  =  P140;  No  =  P141 

P140:  Remove  the  1023  for  this  iteration  of  FNl  from  the  DL31 
list. 

P141:  Remove  the  ID23  for  thfs  iteration  of  FNl  from  the  Pi 
list. 

P142:  Does  the  task  in  this  iteration  of  FNl  require  a 

Scheduling  Notice  (015)  (as  determined  in  P 5)?  Yes  = 

P143;  No  =  P144 

P143:  Use  the  DS24  data  from  P2  to  generate  an  015  output. 

P144:  Is  the  ID23  for  this  iteration  of  FNl  on  the  DL39  list? 

Yes  =  P145;  No  =  P146 

P145:  Erase  the  1023  for  this  iteration  of  FNl  from  the  DL39 
list. 

P146:  Identify  and  itemize  each  of  the  data  entries  on  the  P137 
record.  A  data  entry  is  the  equivalent  to  one  entry  made 
in  P96,  i.e.,  one  set  of  four  data  elements.  Each  such 
set  (entry)  of  four  data  elements  identifies: 

(1)  A  particular  time  slot  for  which  the  task  in  this 
iteration  of  FNl  is  to  be  scheduled;  this  is 
identified  through  a  monthly  schedule  identifier 
(1027),  date  (1-31)  and  time  slot  number  (1-96)). 

(2)  The  P73  counter  (cumulative  number  of  time  slots 
scheduled)  as  of  the  time  that  the  time  slot  in  data 
element  (1)  was  tentatively  scheduled. 
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(3)  The  P74  counter  (number  of  time  slots  scheduled 
since  the  last  interruption)  as  of  the  time  that 
the  time  slot  in  data  element  (1)  was  tentatively 
scheduled. 

(4)  The  P75  counter  (number  of  interruptions)  as  of 
the  time  at  which  the  time  slot  in  data  element 
(1)  was  tentatively  scheduled. 

FNl.4:  FOR  each  of  the  data  entries  on  the  P137  record  (as 
identified  and  numbered  in  P 1 46 ) : 

P147:  Identify  the  ID27  contained  in  data  element  (1)  in  the 
data  entry  for  this  iteration  of  FNl.4. 

P148:  Locate  the  DS27  data  corresponding  to  the  ID27  from  P147. 

P149:  On  the  DS27  data  located  in  P148,  locate  the  time  slot 
equivalent  to  the  day  (1-31)  and  time  slot  number  (1-96) 
contained  in  data  element  (1)  in  the  data  entry  for  this 
iteration  of  FNl.4. 

P150:  Fill  in  the  empty  fields  in  the  time  slot  identified  in 
P149  on  the  DS27  data  identified  in  P148  as  follows:  The 
task  identifier  (ID23)  should  be  the  ID23  for  this 
iteration  of  FNl.  The  answer  to  whether  this  task  needs  a 
Scheduling  Notice  (015)  is  from  P5.  The  time  use  code 
(CT11)  is  from  P7.  The  answer  to  whether  the  task  was 
scheduled  at  the  specification  of  the  user  is  'No'.  The 
answer  as  to  whether  there  are  any  restrictions  (and  the 
type  of  restrictions,  i.e.,  standard,  special  or  both)  on 
the  scheduling  of  this  task,  the  total  standard  hours 
for  completing  this  task  and  the  total  user  specified 
hours  for  completing  this  task  are  from  the  Db24  data  from 
P2.  The  cumulative  number  of  time  slots  scheduled  for 
this  task  should  be  the  time  slot  from  the  second  of  the 
four  data  elements  (i.e.,  the  value  for  the  P73  counter) 
from  the  P137  record  data  entry  in  this  iteration  of 
FNl.4.  The  cumulative  number  of  interruptions  in 
scheduling  the  task  as  of  this  time  slot  is  from  the  last 
of  the  four  data  elements  (i.e.,  the  value  for  the  P 75 
counter)  from  the  P137  record  data  in  this  iteration  of 
FNl.4.  The  time  slot  for  the  next  time  slot  in  which  this 
task  is  scheduled  should  be  the  time  slot  information 
(i.e.,  the  first  of  the  four  data  elements)  on  the  next 
data  entry  on  the  P137  record,  i.e.,  the  data  entry  for 
the  next  iteration  of  FNl.4,  if  any.  If  there  is  none, 
this  value  should  be  left  blank. 

P151 :  NEXT  FNl.4;  end  of  FNl.4,  GO  TO  P152. 

P 152 :  Erase  the  PI 37  record.  Erase  any  remaining  P109  records. 


P155 


:  Are  there  any  1023s  on  the  P22  list? 
(i.e.,  there  are  no  tasks  left  to  be 

P156:  GO  TO  Pi  of  Step  F4A-7. 

P157.  GO  TO  P17  of  Step  F4A-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

015:  Scheduling  Notices 


Yes  =  P156 
scheduled) 


In  this  Step,  the  program  schedules  non-employee  transport  tasks  for 
which  it  was  not  possible  (or  not  necessary)  to  schedule  the  task 
"next  to11  other  alread.y~~scheduled  tasks  that  will  be  conducted  in 
the  s  *e  facility  or  will  involve  the  same  requirement  implementation 
units.  The  processing  for  this  Step  is  very  similar  to  that  in  Step 
F4A-6  and,  therefore,  will  not  be  redescribed  here.  As  with  Step 
F4A-5,  it  may  be  necessary  to  allow  a  task  to  be  scheduled  after  its 
due  date,  if  any,  if  all  other  scheduling  options  for  the  task  have 
failed. 

PREVIOUS  STEP:  Step  F4A-7  follows  P16  of  Step  F4A-2  and  P156  of 
Step  F4A-6. 


FUNCTION  F4B 


Rescheduling  Function 
(Functional  Data  Flow) 


In  this  Function  the  OHMIS  program  identifies  those  tasks  that  need  to 
be  rescheduled  and  makes  the  necessary  changes  in  the  OHMIS  data 
base  for  rescheduling  them.  With  the  exception  of  the  user  specified 
scheduling  of  tasks  (done  in  Step  F4B-7),  the  actual  rescheduling  is 
done  in  Function  F4A  in  the  same  way  as  the  original  scheduling  of  the 
task  was  done. 

There  are  several  different  specific  reasons  why  tasks  may  need  to 
be  rescheduled.  Each  Step  of  Function  F4B  identifies  the  tasks  that 
need  to  be  rescheduled  for  one  of  these  different  reasons.  The 
basic  reason  why  tasks  need  to  be  rescheduled  is  the  same,  however, 
in  all  Steps,  namely,  that  the  user  makes  some  change  to  the  OHMIS 
data  base  which  affects  the  scheduling  of  one  or  more  tasks  so  that 
they  are  no  longer  scheduled  appropriately.  For  example,  if  the  user 
indicates  that  a  task  of  the  type  that  in  most  cases  takes  two  hours 
is,  for  this  particular  task,  going  to  task  three  hours,  this  is  a 
change  in  the  data  affecting  the  scheduling  of  the  task  and  the  task 
will  have  to  be  rescheduled.  Similarly,  if  the  user  indicates  that  a 
performer  of  tasks  no  longer  has  a  certain  time  available  for 
scheduling  which  was  formerly  shown  as  available,  then  the  tasks 
scheduled  for  that  time  will  need  to  be  rescheduled. 
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In  this  Step  the  program  identifies  all  of  the  tasks  that  need  to  be 
rescheduled  as  a  result  of  a  change  in  the  task  scheduling 
restrictions  information  given  on  the  contact  and  location  data 
(DS28).  It  also  makes  the  necessary  corresponding  changes  on  the  DS27 
data. 

PREVIOUS  STEP:  None,  initiated  by  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval): 

Menu  Selection  and  Input  Sequence: 

SI:  8  (Address  data) 

S2:  2  (contact  and  location  data) 

S3:  2  (change  task  scheduling  restrictions  data) 

El:  Contact  identifier  (1026) 

E2:  Answer  (Yes/No  for  whether  or  not  there  are  any 

standard  restrictions  for  the  identifier  for  which 
the  user  is  changing  restrictions  information.  Entry 
in  in  P3.) 

E3:  Weekly  schedule  identifier  (ID28),  i.e.,  identifier 

for  the  weekly  schedule  data  (DS26)  containing  the 
new  information  about  restrictions .  Entry  is  in  P6. 

Data  Retrievals : 


Rl: 

OHMIS  user  type  (CT1).  From  P2  of  Step  F1A- 

2. 

R2; 

OHMIS  service  area  identifier  (ID10)  for  the 
executing  Step  F4B-1  at  this  time.  Retained 
Step  F1A-2. 

user 

in  P5  of 

DS24: 

Specific  task  scheduling  data 

DS26 : 

Regular  weekly  schedule  availability  data 

DS27 : 

Monthly  schedule  data  (availability  and  use) 

DS  28: 

Contact  and  location  data 

DL36 : 

List  of  requirement  implementation  units  (or  sets  of 
units)  linked  to  their  corresponding  task  identifier 
(ID23),  OHMIS  service  area  identifier  (ID10)  and 
whether  the  task  is  an  'employee  transport’  type  of 

task 
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DL43:  List  of  weekly  schedule  identifiers  (ID28)  by  contact 
identifiers  (ID26)  and  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)} : 

PI:  Ask  user  for  El  (contact  identifier  (ID26))  for  the 

particular  set  of  0S28  data  for  which  the  user  wishes  to 
change  scheduling  restrictions  information. 

P2:  Locate  the  DS28  data  corresponding  to  the  1026  entered  in 

PI. 

P3:  Ask  the  user  for  E2  (whether  or  not  there  are  any 

restrictions).  Enter  this  answer  onto  the  DS28  data 
located  in  P2. 

P4:  Was  the  answer  given  in  P3  a  'Yes'  or  a  'No'?  Yes  =  P6; 

No  =  P5 

P5:  End  of  Function  F48;  close  out  and  exit  to  the  appropriate 

Menu  'O'  (First  Level  Menu)  as  determined  by  the  CT1  from 
Rl. 

P6:  Ask  the  user  for  E3  (regular  weekly  schedule  identifier 

( 1028) )  for  the  DS26  data  contairing  the  information  about 
the  restrictions  applicable  to  the  identifier  for  which 
the  DS28  data  located  in  P2  provides  contact  and  location 
data.  Enter  this  1028  onto  the  DS28  data  located  in  P2. 
Also  enter  this  1028  and  the  ID26  from  Pi  and  the  ID10 
from  R2  onto  the  DL43  list. 

P7:  Identify  the  identifier  on  the  0S28  data  located  in  P2  of 

the  person  or  thing  for  which  that  set  of  0S28  data 
provides  contact  and  location  data.  (Note:  This  is  not 
the  contact  person,  but  the  unit  about  which  the  DS28 
data  is  providing  contact  information.) 

P8:  Examine  the  DL36  list  and  determine  if  there  are  any  tasks 

corresponding  to  the  requirement  implementation  unit 
identified  in  P7  and  the  ID10  from  R2.  Yes  =  P9;  No  =  P5 

P9:  Generate  a  temporary  list,  called  the  P9  list.  Enter  the 

task  identifiers  (1023)  for  all  tasks  listed  on  the  DL36 
list  that  are  for  the  requirement  implementation  unit 
identified  in  P7  and  the  I DIO  from  R2. 

P10:  Locate  the  DS26  data  corresponding  to  the  1028  entered  as 

E2  in  P6.  Identify  the  start  and  end  dates  of  this  set  of 
DS26  data. 

FN1:  FOR  each  ID3  on  the  P9  list: 
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Pll:  Locate  the  DS24  data  corresponding  to  the  ID23  for  this 

iteration  of  FNl. 

P12:  Does  the  DS24  data  located  in  Pll  show  that  the  task  for 

this  iteration  of  FNl  is  currently  scheduled?  Yes  =  P13; 
No  =  P20  (next  FNl) 

P13:  Using  the  DS24  data  from  Pll,  identify  the  time  slot 

information  for  the  start  time  in  which  the  task  in  this 
iteration  of  FNl  is  scheduled  to  begin. 

P 14 :  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (ID27)  that  is  part  (1)  of  the  start  time  slot 
information  identified  in  PI 3 - 

FNl.l;  FOR  each  of  the  time  slots  on  the  DS27  data  from  P14  (or 
succeeding  DS27  data  sets)  on  which  the  task  for  this 
iteration  of  FNl  is  currently  scheduled,  beginning  with 
the  time  slot  identified  in  P 13 : 

P15:  Locate  the  time  slot  on  the  DS27  data  for  this  iteration 

of  FNl.l.  (Note:  This  is  the  same  as  the  DS27  data  from 
P14  on  the  time  slot  identified  in  P13,  for  the  first 
iteration  of  FNl.l.  The  information  in  the  P13  time  slot 
and  each  succeeding  time  slot  will  show  the  next  time  slot 
in  which  the  task  is  scheduled.  Therefore,  each  iteration 
of  FNl.l  involves  identifying  the  next  time  slot  that  will 
constitute  the  time  slot  for  the  next  iteration  of  FNl.l. 
The  next  time  slot  will  not  necessarily  be  on  the  same 
DS27  data  (i.e.,  will  not  necessarily  have  the  same  ID27), 
as  the  preceding  one,  if  the  task  is  scheduled  for  more 
than  one  month.) 

P16:  Is  the  year,  month  and  day  of  the  month  for  the  DS27  time 

slot  located  in  P15  within  the  dates  covered  by  the  DS26 
data  located  in  P10?  (Note:  The  year  and  month  for  the 
DS27  data  are  given  at  the  top  of  the  DS27  data  (a  set  of 
DS27  data  covers  only  one  month);  the  date  of  the  month  is 
given  as  a  part  of  the  time  slot  information  for  the  time 
slot  located  in  P15.  To  be  "covered"  by  the  DS26  data, 
the  time  slot  from  P 15  must  be  between  the  start  and  end 
dates  for  the  DS26  data  as  identified  in  P10.)  Yes  =  P 1 7 ; 
No  =  P19  (next  FNl.l) 

P17:  Identify  the  day  of  the  week  (1-7)  and  the  time  slot 

number  (1-96)  on  the  time  slot  located  in  P15.  (This 
information  is  on  the  DSZ7  data.) 

P18:  Locate  the  time  slot  on  the  DS26  data  from  P10  that 

corresponds  to  the  day  of  the  week  and  the  time  slot 
number  identified  in  P 1 7 .  Does  the  DS26  data  show  that 
this  time  slot  is  restricted  (i.e.,  not  available  for 
scheduling)?  Yes  =  P20;  No  =  P 19  (next  FNl.l) 
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PI 9:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P21. 

P20:  Generate  a  list  called  the  P21  list  and  put  the  ID23  for 

this  iteration  of  FNl  onto  the  P20  list;  or,  if  the  P20 
list  already  exists  (i.e.,  P20  has  already  been  reached  in 
this  execution  of  Step  F4B-1)  check  the  P20  list  to 
determine  if  the  1023  for  this  iteration  of  FNl  is  already 
on  the  P20  list;  if  it  is,  continue;  if  it  is  not,  add  the 
1023  to  the  P20  list  and  then  continue. 

P21:  NEXT  FNl;  end  of  FNl,  GO  TO  P22. 

P22:  Are  there  any  1023s  on  the  P20  list?  Yes  =  P23;  No  =  P5 

P23:  GO  TO  PI  of  Step  F4B-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F4B-2 


In  this  Step,  the  program  modifies  the  OHMIS  data  base  to  reflect  the 
tasks  that  need  to  be  rescheduled.  These  tasks  have  been  identified 
in  other  Steps  of  Function  F4B. 

PREVIOUS  STEP:  Step  F4B-2  follows  P23  of  Step  F4B-1;  P33  of  Step 
F4B-3;  P16  of  Step  F4B-4;  Step  F4B-51;  P8  of  Step  F4B-6;  and  P26  of 
Step  F48-7. 

INPUTS  (R  =  Retrieval): 

Menu  Selection  and  Input  Sequence:  None 


Data  Retrievals: 


Rl: 

OHMIS  service  area  identify  ID10)  for  the  user 

executing  Step  F4B-2.  From  Step  F1A-2. 

R2: 

List  of  task  identifiers  (IL.  for  the  tasks  that 

need  to  be  rescheduled  from  P19  of  Step  F4B-1 

R3: 

List  of  task  identifiers  (ID23)  for  ta^ks  that  need 
to  be  rescheduled  from  PI  of  Step  F4B-3 

R4: 

List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  from  PI  of  Step  F4B-4 

R5: 

List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  from  PI  of  Step  F4B-5 

R6: 

List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  from  PI  of  Step  F4B-6 

R7: 

List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  from  PI  of  Step  F4B-7 

DS24: 

Specific  task  scheduling  data 

DS27 : 

Monthly  schedule  data  (availability  and  use) 

DL39: 

List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  = 
loop)) : 

Process  substep;  FN  =  For  Next  (program  logic 

PI: 

Add 

the  R2  through  R7  lists  together  and  form  one  list, 

cal  led  the  PI  1 ist. 

FNl: 

FOR 

each  task  identifier  (ID23)  on  the  PI  list: 

P2:  Add  the  ID23  for  this  iteration  of  FNl  and  the  ID10  from 

Rl  to  the  DL39  list. 


A-n i 
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P3:  Locate  the  DS24  data  corresponding  to  the  ID23  for  this 

iteration  of  FNl. 

P4:  Using  the  DS24  data  from  P3,  identify  the  time  slot 

information  for  the  start  time  of  the  task  in  this 
iteration  of  FNl. 

P5:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (1027)  that  is  part  (1)  of  the  time  slot 
information  located  in  P4. 

P6:  Change  the  answer  on  the  DS24  data  from  P3  as  to  whether 

this  task  is  scheduled  to  be  a  'No1  and  enter  the  code  'C* 
(task  must  be  rescheduled)  as  an  explanation  for  why  the 
task  is  not  scheduled.  Also  erase  all  scheduling 
information  from  this  DS24  data,  i.e.,  the  information 
about  the  scheduling  of  the  task  as  it  was  previously 
scheduled  (e.g.,  start  and  end  time  slot  information, 
whether  the  task  was  scheduled  before  the  due  date,  number 
of  interruptions,  etc.).  Do  not  erase  the  information 
about  whether  more  than  one  person  will  perform  this  task. 

FN1.1:  FOR  each  time  slot  in  which  the  task  for  this  iteration 
of  FNl  was  previously  scheduled  beginning  with  the  start 
time  slot  identified  in  P4  and  the  DS27  data  located  in  P5 
and  continuing  with  the  time  slot  identified  in  P9: 

P7:  Locate  the  time  slot  for  this  iteration  of  FNl . 1 .  (Follow 

the  instructions  given  in  P15  of  Step  F4B-1.) 

P8:  Determine  whether  the  scheduling  of  the  task  continues. 

(This  is  shown  on  the  DS27  data  for  the  time  slot  in  this 
iteration  of  FN1.1  as  located  in  P7.)  Yes  =  P9;  No  =  P 12 

P9:  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  continues.  (From  the  DS27  data  for  the  P7  time 
slot. ) 

P 10 :  Erase  all  or  the  scheduling  information  for  the  task  in 

this  iteration  of  FNl  from  the  DS27  time  slot  located  in 
P  7. 

Pi  1 :  NEXT  FNl.l.  (End  of  FNi.l  will  not  be  reached.) 

P 12 :  Using  the  0S24  data  from  P3,  determine  if  there  is  more 

than  one  person  scheduled  to  perform  this  task.  Yes  = 

P14;  No  =  P13 

P13:  GO  TO  P5  of  Step  F4B-1. 


P 14 : 


Identify  the  up  to  3  monthly  schedule  identifiers  (ID27) 
on  the  L)S24  data  located  in  P3  that  specify  the  monthly 
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schedule  data  (DS27)  on  which  the  scheduling  for  the  task 
for  the  additional  persons  scheduled  to  perform  the  task 
is  shown  to  start.  Put  the  starting  DS27s  on  a 
temporary  list,  called  the  P14  list. 

FN1.2;  FOR  each  1027  on  the  P14  list: 

P15:  Locate  the  DS27  data  corresponding  to  the  ID27  for  this 

iteration  of  FNl . 2 . 

FNl.2.1:  FOR  each  time  slot  in  which  the  task  in  this  iteration 
of  FNl  is  already  scheduled  and  is,  therefore,  also 
scheduled  for  an  additional  person  to  perform  the  task  at 
the  same  time,  beginning  with  the  date  of  the  month  and 
the  time  slot  number  that  are  parts  (2)  and  (3)  of  the 
start  time  slot  identified  in  P4  on  the  DS27  data  located 
in  P15  and  continuing  with  the  time  slot  identified  in 
P18. 

P16:  Locate  the  time  slot  for  this  iteration  of  FNl. 2.1. 

(Following  the  instructions  given  in  P15  of  Step  F4B-1.) 

P17:  Determine  whether  the  scheduling  of  the  task  continues  to 

another  time  slot.  (This  information  is  shown  on  the  DS27 
data  for  the  time  slot  for  this  iteration  of  FNl. 2.1  as 
located  in  P16.)  fes  =  P18;  No  =  P21  (next  FNl .2) 

P 18 :  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  will  continue.  (From  the  DS27  data  for  the  P16 
time  slot.) 

P19:  Erase  all  of  the  scheduling  information  for  the  task  in 

this  iteration  of  FNl  from  the  DS27  data  time  slot  located 
in  P16. 

P20:  NEXT  FNl. 2.1.  (End  of  FNl. 2.1  will  not  be  reached.) 

P21 :  NEXT  FNl. 2;  end  of  FNl. 2,  GO  TO  P22. 

P22:  Change  the  answer  to  the  question  on  the  DS24  data  located 

in  P3  about  whether  there  are  additional  persons  scheduled 
to  perform  this  task  to  be  'No'.  Erase  the  information 
about  the  additional  persons  previously  scheduled  to 
perform  this  task  shown  on  the  DS24  data. 

P23:  GO  TO  P13. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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In  this  Step,  the  program  identifies  the  tasks  that  need  to  be 
rescheduled  due  to  the  deactivation  of  regular  weekly  availability 
data  (DS26).  The  program  also  identifies  and  erases  the  monthly 
schedule  data  (0S27)  that  should  be  erased  as  a  result  of  the  DS26 
data  being  deactivated. 

PREVIOUS  STEP:  None,  initiated  by  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  7  (scheduling  data) 

S2:  2  (regular  weekly  schedule  data) 

S3:  2  (deactivate  regular  weekly  schedule  data) 

Ql:  Weekly  schedule  identifier  (ID28)  for  the  weekly 

schedule  data  (DS26)  the  user  wishes  to  deactivate. 
Query  is  in  P2. 

El:  Deactivation  date.  Entry  is  in  P4. 

Data  Retrievals: 

Rl:  OHMIS  service  area  identifier  (ID10)  for  the  user 

executing  Step  F4B-3.  From  P5  of  Step  F1A-2. 

DS26:  Regular  weekly  schedule  availability  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

DL33:  List  of  monthly  schedule  identifiers  (ID27)  by  OHMIS 
service  area  < ID10 ) 

DL41 :  List  of  monthly  schedule  identifiers  (ID27)  for  an 
_  OHMIS  service  area  (ID10)  with  the  corresponding  year 

and  month  covered  by  the  monthly  schedule  data  (DS27) 
identified  by  the  ID27  and  the  employee  identifier 
(ID4)  of  the  employee  performing  the  tasks  scheduled 
on  this  DS27  data 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Start  a  list,  called  the  PI  list.  This  will  be  a  list  of 

the  task  identifier  (ID23)  for  the  tasks  that  need  to  be 
rescheduled. 
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P2:  Ask  the  user  for  Q1  (weekly  schedule  identifier  ( ID28) )  of 

the  DS26  data  he/she  wishes  to  deactivate. 

P3:  Locate  the  0S26  data  corresponding  to  the  ID28  from  P2. 

P4:  Ask  the  user  for  El  (deactivation  date).  Enter  this  date 

on  the  DS26  data  located  in  P3. 

P5:  Identify  the  employee  identifier  (ID4)  on  the  0S26  data 

from  P3  that  is  a  person  for  whom  the  DS26  data  provides 
weekly  schedule  availability  data. 

P6:  Determine  if  there  are  any  entries  on  the  DL41  list  for 

the  employee  identifier  from  P5  and  for  the  year  and  month 
equal  to  later  than  the  year  and  month  of  the  date  entered 
in  P4.  Yes  =  P8;  No  =  P7 

P7:  GO  TO  P5  of  Step  F4B-1. 

P8:  Identify  the  entries  (ID27s)  on  the  DL41  list  that  are  for 

the  ID4  from  P5  and  are  for  the  year  and  month  equal  to  or 
later  than  the  year  and  month  from  P4.  Put  these  monthly 
schedule  identifiers  (ID27)  on  a  temporary  list  called  the 
P8  list. 

FNl:  FOR  each  ID27  on  the  P8  list: 

P9:  Locate  the  DS27  data  corresponding  to  the  ID27  for  this 

iteration  of  FNl. 

P10:  Identify  the  year  and  month  covered  by  the  DS27  data  from 

P9.  (This  information  is  on  the  DS27  data.)  Is  this  the 
same  year  and  month  as  the  date  entered  in  P4?  Yes  = 

FNl .  1  (Pll) ;  No  =  FNl. 2  (P20) 

FNl . 1 :  FOR  each  day  of  the  month  on  the  DS27  data  located  in 
P9: 

Pll:  Is  the  day  of  the  month  for  this  iteration  of  FNl.l  equal 

to  or  later  than  the  day  of  the  month  for  the  date  entered 
in  P 4?  Yes  =  P12;  No  =  P19  (next  FNl.l) 

P 12 :  Is  the  answer  for  the  question  about  availability  for 

scheduling  for  the  entire  day  of  the  month  for  this 
iteration  of  FNl.l  on  the  DS27  data  from  P9  a  'Yes'  or 
'No'?  Yes  =  P13;  No  =  P19  (next  FNl.l) 

P13:  Enter  the  answer  'No'  for  the  question  about  the 

availability  for  scheduling  for  the  entire  day  for  the  day 
of  the  month  in  this  iteration  of  FNl.l  onto  the  DS27  data 
from  P9. 
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FN1.1.1:  FOR  each  time  slot  (1-96)  on  the  day  of  the  month  for 
this  iteration  of  FNl.l: 

P14:  Locate  the  time  slot  for  this  iteration  of  FNl.l  on  the 

DS27  data  from  P9. 

P15:  Enter  the  answer  'No'  for  the  question  about  availability 

for  scheduling  for  the  time  slot  located  in  P14. 

P16:  Is  there  a  task  scheduled  in  the  time  slot  for  this 

iteration  of  FNl.1.1?  Yes  =  P17;  No  =  P18  (next  FNl.1.1) 

P17:  Identify  the  task  identifier  (1023)  for  the  task  scheduled 

in  the  time  slot  for  this  iteration  of  FNl.1.1.  Check  the 
PI  list  to  determine  if  this  ID23  is  already  on  the  PI 
list.  If  'No',  add  this  1023  to  the  PI  list  and  continue; 
if  'Yes',  just  continue. 

P18:  NEXT  FNl.1.1;  end  of  FNl.1.1,  GO  TO  P19. 

P19:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P31  (next  FNl) . 

FN1.2:  FOR  each  day  of  the  month  on  the  DS27  data  located  in 
P9: 

P20:  Is  the  answer  for  the  question  about  the  availability  for 

scheduling  for  the  entire  day  for  this  iteration  of  FNl. 2 
on  the  DS27  data  from  P9  a  'Yes'  or  'No'?  Yes  =  FNl. 2.1 
(P21) ;  No  =  P27  (next  FNl. 2) 

FNl. 2.1:  FOR  each  time  slot  (1-96)  on  the  day  of  the  month  for 
this  iteration  of  FNl. 2: 

P21:  Locate  the  time  slot  for  this  iteration  of  FNl. 2.1  on  the 

DS27  data  from  P9. 

P22:  Is  there  a  task  scheduled  in  the  time  slot  for  this 

iteration  of  FNl. 2.1?  Yes  =  P23;  No  =  P26  (next  FNl. 2.1) 

P23:  Identify  the  task  identifier  (ID23)  for  the  task  that  is 

scheduled  in  the  time  slot  for  this  iteration  of  FNl. 2.1. 

P24:  Is  the  ID23  identified  in  P23  already  on  the  PI  list?  Yes 

»  P26;  No  =  P25 

P25:  Add  the  ID23  identified  in  P23  to  the  PI  list. 

P26:  NEXT  FNl. 2.1,  end  of  FNl. 2.1,  GO  TO  P27. 


P27:  NEXT  FNl. 2,  end  of  FNl. 2,  GO  TO  P28. 


Erase  the  0S27  data  located  in  P9. 
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P29:  Erase  the  entire  entry  for  the  ID27  from  this  iteration  of 

FNl  from  the  DL33  list. 

P30:  Erase  the  entire  entry  for  the  ID27  for  this  iteration  of 

FNl  from  the  DL41  list. 

P31;  NEXT  FNl;  end  of  FNl,  GO  TO  P32. 

P32:  Are  there  any  entries  on  the  Pi  list?  Yes  =  P33;  No  =  P7 

P33:  GO  TO  PI  of  Step  F4B-2. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 


STEP  F4B-4 


In  this  Step,  the  program  identifies  the  tasks  that  need  to  be 
rescheduled  because  of  a  change  in  the  restrictions  or  availability 
for  scheduling  data  on  the  regular  weekly  schedule  data  (DS26).  It 
also  makes  the  necessary  changes  on  the  DS27  data.  It  also  allows  the 
user  to  enter  changes  in  preferred  time  use  (CT11)  on  the  DS26  data 
and  makes  the  corresponding  changes  on  the  DS27  data  and,  if 
necessary,  on  the  0S24  data. 

PREVIOUS  STEP:  None,  initiated  by  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  7  (scheduling  data) 

S2:  2  (regular  weekly  schedule  data) 

S3:  3  (change  regular  weekly  schedule  data) 

Ql:  Weekly  schedule  identifier  (ID26)  of  the  regular 

weekly  schedule  data  (DS28)  that  the  user  wishes  to 
change.  Query  is  in  P2. 

Q2:  Day  of  the  week  (1-7)  that  the  user  wishes  to  change. 

Query  is  in  P4. 

Q3:  Whether  the  user  wishes  to  change  availability 

information  or  preferred  time  use  (CT11)  information. 
Query  is  in  P5. 

El:  Whether  the  user  wishes  to  enter  that  the  entire  day 

is  not  available  for  scheduling.  Query  is  in  P6. 

Q4:  Time  slot  number  (1-96)  that  the  user  wishes  to 

change.  Query  is  in  P9  and  P61. 

E2:  Whether  time  slot  is  available  for  scheduling. 

Answers:  Yes/No.  Entry  is  in  P10. 

E3:  Preferred  time  use  code  (CT11)  for  the  time  slot. 

E.ntry  is  in  P63. 

Data  Retrievals: 

Rl:  OHMIS  service  area  identifier  ( 1010)  for  the  user 

executing  Step  F4B-4.  Retained  in  P5  of  Step  F1A-2. 

DS24:  Specific  task  scheduling  data 
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DS26:  Regular  weekly  schedule  availability  data 

0S27:  Monthly  schedule  data  (availability  and  use) 

DS28:  Contact  and  location  data 

DL36:  List  of  requirement  implementation  units  (or  sets  of 
units)  linked  to  their  corresponding  task  identifier 
(ID23),  OHMIS  service  identifier  (1010)  and  whether 
the  task  is  an  'employee  transport*  type  of  task 

DL41:  List  of  the  monthly  schedule  identifiers  (ID27)  for 
an  OHMIS  service  area  (ID1Q)  with  the  corresponding 
month  and  year  covered  by  the  monthly  schedule  data 
(0S27)  identified  by  the  1027  and  the  employee 
identifier  (104)  of  the  employee  performing  the  tasks 
scheduled  on  this  DS27  data 

DL43:  List  of  weekly  schedule  identifiers  (ID28)  by  contact 
identifier  (1026)  and  by  OHMIS  service  area  (ID10) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Start  a  list,  called  the  PI  list,  of  task  identifiers 

(1023)  for  the  task  that  will  need  to  be  rescheduled. 

P2:  Ask  the  user  for  query  (weekly  schedule  identifier  (ID28)) 

of  the  0S26  data  that  the  user  wishes  to  change. 

P3:  Locate  the  DS26  data  with  the  1D28  from  P2.  Identify  the 

start  and  end  dates  of  this  set  of  0S26  data. 

P4:  Ask  the  user  for  Q2  (day  of  the  week  (1-7)  that  the  user 

wishes  to  change). 

P5:  Ask  the  user  for  Q3  (whether  user  wishes  to  change 

availability  information  or  preferred  time  use  code 
(CT11)).  Availability  information  *  P6;  CT11  =  P16 

P6:  Ask  the  user  for  El  (whether  any  of  the  time  slots  on  the 

day  of  the  week  obtained  in  P 4  are  to  be  available  for 
scheduling).  Yes  =  P9;  No  =  P7  (Note:  Retain  this 
answer  throughout  Step  F48-4.) 

P 7 :  Enter  the  answer  'No'  to  the  question  about  availability 

for  scheduling  for  the  day  of  the  week  obtained  in  P4  on 
the  0S26  data  from  P3.  Also  enter  the  answer  of  'No'  for 
the  question  as  to  whether  the  time  slot  is  available  for 
scheduling  onto  each  of  the  time  slots  on  the  DS26  data 
from  P3  for  the  day  of  the  week  from  P4. 
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P8:  Is  the  DS26  data  from  P3  restricted  times  type  of  0S26 

data?  Yes  =  P20;  No  =  P37 

P9:  Ask  the  user  for  Q4  (time  slot  number  (1-96)  that  the  user 

wishes  to  change). 

P10:  Ask  user  for  E2  (whether  the  time  slot  is  available  for 

scheduling).  Answers:  Yes/No 

Pll:  Locate  the  time  slot  on  the  DS26  data  from  P3  that  is  for 

the  day  of  the  week  from  P4  and  the  time  slot  number  from 
P9.  Enter  the  answer  given  in  P10  onto  the  DS26  data  for 
the  question  about  the  availability  for  scheduling  for 
this  time  slot. 

P 12 :  Is  the  DS26  data  from  P3  restricted  times  type  of  DS26 

data?  Yes  =  P13;  No  =  P37 

P13:  Was  the  answer  given  in  P10  a  'Yes'  or  a  'No'?  Yes  =  P14; 

No  =  P18 

P14:  Ask  the  user  for  Q5  (whether  the  user  has  more  changes). 

Yes  =  P4;  No  =  P15 

P15:  Are  there  any  entries  (ID23s)  on  the  PI  list?  Yes  =  P16; 

No  =  P 1 7 

P16:  GO  TO  PI  of  Step  F4B-2. 

P17 :  GO  TO  P5  of  Step  F4B-1. 

P18:  Check  whether  there  are  any  time  slots  on  the  0S26  data 

from  P3  for  the  day  of  the  week  from  P4  that  have  an 
answer  of  'Yes'.  Yes  =  P20;  No  «  P19 

P19:  Enter  the  answer  'No'  for  the  answer  to  the  question  about 

availability  for  scheduling  in  the  field  corresponding  to 
the  day  of  the  week  from  P4  onto  the  DS26  data  from  P3. 

P20:  Are  there  any  entries  (i.e.,  contact  identifiers  (1026)) 

on  the  0S43  list  for  the  1028  entered  in  P2  and  the  IDlO 

from  Rl?  Yes  =  P21;  No  =  P14 

P21:  Identify  each  of  the  1026s  on  the  DS43  list  for  the  ID28 

from  P2  and  the  IDlO  from  Rl.  Enter  onto  a  temporary 

list,  cal  led  the  P21  list. 

FNl:  FOR  each  1026  on  the  P21  list: 

P22:  Locate  the  DS28  data  corresponding  to  this  ID26. 
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P23:  Identify  the  identifier  of  the  person  or  thing  for  which 

the  DS28  data  from  P22  provides  contact  and  location  data. 
(Note:  This  is  not  the  contact  person  (104)  given  on  the 
0S28  data,  but  the  person  or  thing  about  which  the  DS28 
data  provides  contact  information. ) 

P24:  Examine  the  DL36  list  and  determine  if  there  are  any  tasks 

corresponding  to  the  requirement  implementation  unit 
identifier  identified  in  P23  and  the  ID10  from  Rl.  Yes  = 
P25;  No  =  P36  (next  FNl) 

P25:  Generate  a  temporary  list,  called  the  P25  list.  Enter  the 

task  identifiers  (1023)  for  all  tasks  listed  on  the  DL36 
list  that  are  for  the  requirement  implementation  unit 
identified  in  P3  and  the  1010  from  Rl  onto  the  P25  list. 

FNl.l:  FOR  each  1023  on  the  P20  list: 

P26:  Locate  the  DS24  data  corresponding  to  the  ID23  for  this 

iteration  of  FNl.l. 

P27:  Does  the  DS24  data  located  in  P26  show  that  the  task  for 

this  iteration  of  FNl.l  is  currently  scheduled?  Yes  = 

P28;  No  =  P38  (next  FNl.l) 

P28:  Using  the  OS 24  data  from  P2 6,  identify  the  time  slot 

information  for  the  time  slot  in  which  the  task  in  this 

iteration  of  FNl.l  is  scheduled  to  start. 

P29:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (ID27)  that  is  part  (1)  of  the  start  time  slot 
information  identified  in  P28. 

FNl. 1.1:  FOR  each  time  slot  on  the  DS27  data  from  P29  (or 
succeeding  DS27  data  sets)  on  which  the  task  in  this 
iteration  of  FNi.l  is  currently  scheduled,  beginning  with 
the  start  time  slot  identified  in  P28  and  the  DS27  data 
from  P29: 

P30:  Locate  the  time  slot  for  this  iteration  of  FNl. 1.1. 

(Follow  the  instructions  given  in  P 15  of  Step  F4B-1.) 

P31:  Is  the  year,  month  and  day  of  the  month  for  the  DS27  time 

slot  located  in  P30  within  the  dates  covered  by  the  DS26 
data  located  in  P3?  Yes  =  P32;  No  =  P33  (next  FNl. 1.1) 

P32:  Identify  the  time  slot  on  the  DS26  data  from  P3  that  is 

the  same  time  slot  (i.e.,  the  same  day  of  the  week  and 
time  slot  number)  as  that  located  on  the  DS27  data  in  P30. 
Does  this  DS26  time  slot  indicate  that  the  time  slot  is 
available  for  scheduling?  Yes  =  P33  (next  FNl. 1.1);  No  = 
P34 
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P33:  NEXT  FNl.1.1;  end  of  FNl. 1.1,  GO  TO  P35. 

P34:  Check  the  PI  to  determine  if  the  1023  for  this  iteration 

of  FNl.l  is  already  on  the  PI  list;  if  not,  pul  the  1023 
on  the  PI  list  and  continue;  otherwise,  just  continue. 

P35:  NEXT  FNl.l;  end  of  FNl.l,  GO  TO  P36. 

P36:  NEXT  FNl;  end  of  FNl,  GO  TO  P14. 

P37:  (From  P8  and  P12):  Identify  the  employee  identifier  (ID4) 

on  the  DS26  data  from  P3  of  the  person  for  whom  this  set 
of  0S26  data  provides  weekly  schedule  availability  data. 

P38:  Determine  if  there  are  any  entries  (ID27)  on  the  DL41  list 

for  the  ID4  from  P 37  and  the  ID 10  from  Rl.  Yes  =  P39;  No 
=  P14 

P39:  Identify  each  of  the  ID27s  on  the  0L41  list  for  the  104 

from  P37  and  the  1010  from  Rl.  Enter  onto  a  temporary 
list,  called  the  P39  list. 

FN2:  FOR  each  of  the  1027s  on  the  P39  list: 

P40:  Locate  the  DS27  data  corresponding  to  the  1027  for  this 

iteration  of  FN2. 

FN2.1:  FOR  each  of  the  days  of  the  month  on  the  DS27  data 

located  in  P40  (or  for  the  day  of  the  month  identified  in 
P48,  if  one  has  been  identified): 

P41:  Identify  the  day  of  the  week  for  the  day  of  the  month  in 

this  iteration  of  FN2.1  (as  shown  on  the  DS27  data).  Is 
this  day  of  the  week  the  same  as  the  day  of  the  week  from 
P4?  Yes  =  P42;  No  =  P59  (next  FN2.1) 

P42:  Was  the  answer  to  the  question  in  P6  a  'Yes'  or  a  'No'? 

Yes  =  P43;  No  =  FN2.1.1  (P55) 

P43:  Identify  the  time  slot  (1-96)  on  the  OS27  data  from  P40 

and  for  the  day  of  the  month  for  this  iteration  of  FN2.1 
that  is  the  same  as  the  time  slot  entered  in  P9. 

P44:  Was  the  answer  given  in  P10  a  'Yes'  or  a  'No'?  Yes  =  P45; 

No  =  P50 

P45:  Fill  the  question  about  availability  for  scheduling  on  the 

0S27  data  from  P40  for  the  time  slot  identified  in  P43 
with  the  answer  'Yes'. 


P46:  Derive  the  sum  that  is  equal  to  the  day  of  the  month  for 

this  iteration  of  FN2.1,  plus  '7'. 
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P47:  Is  there  a  day  of  the  month  on  the  DS27  data  from  P40  that 

is  equal  to  the  value  derived  in  P46?  (Note:  To  answer 
this  question,  examine  the  last  day  of  the  month  on  the 
DS27  data  and  determine  if  it  is  less  than  the  value 
derived  in  P46.)  Yes  =  P48;  No  =  P60  (next  FN2) 

P48:  Identify  the  day  of  the  month  on  the  DS27  data  from  P4 

with  the  value  derived  in  P46.  Store  this  date. 

P49:  Is  the  answer  to  the  question  in  P42  a  'Yes'  or  a  'No1? 

Yes  =  P59  (next  FN2) ;  No  =  P54 

P50:  Is  there  a  task  scheduled  in  the  time  slot  identified  in 

P43?  Yes  =  P51 ;  No  =  P52 

P51:  Identify  the  task  identifier  (ID23)  for  the  task  that  is 

scheduled  in  the  time  slot  identified  in  P43.  Check  the 
PI  list  to  determine  if  this  ID23  is  already  on  the  PI 
list;  if  not,  place  this  ID23  on  the  PI  list  and  continue; 
if  it  is,  simply  continue. 

P52:  Fill  the  question  about  availability  for  scheduling  on  the 

DS27  data  from  P40  for  the  time  slot  identified  in  P43 
with  the  answer  'No*. 

P53:  GO  TO  P46. 

P54:  Generate  a  flag,  called  the  P54  flag  (if  such  a  flag  has 

not  already  been  generated). 

FN2.1.1:  FOR  each  time  slot  (1-96)  on  the  day  of  the  month  for 
this  iteration  of  FN2.1  (or  the  time  slot  identified  in 
P48  if  there  is  a  flag  in  P54),  for  the  DS27  data  located 
in  P40: 

P55:  Fill  in  the  answer  to  the  question  about  availability  for 

scheduling  for  the  time  slot  in  this  iteration  of  FN2.1.1 
with  the  answer  ' No' . 

P56:  Is  there  a  task  scheduled  in  the  time  slot  for  this 

iteration  of  FN 2.1.1?  Yes  =  P 57;  No  =  P58  (next  FN2.1.1) 

P57:  Identify  the  task  identifier  (ID23)  for  the  task  that  is 

scheduled  in  the  time  slot  for  this  iteration  of  FN2.1.1. 
Check  to  determine  if  this  ID23  is  already  on  the  Pi  list; 
if  not,  enter  it  on  the  PI  list  and  continue;  otherwise, 
simply  continue. 

P58:  NEXT  FN2.1.1;  end  of  FN2.1.1,  GO  TO  P46. 


P59:  NEXT  FN2.1  end  of  FN2.1,  GO  TO  P60. 
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P60:  NEXT  FN2;  end  of  FN2,  GO  TO  P14. 

P61:  (From  P5):  Ask  user  for  Q4  (time  slot  number  (1-96)  that 

the  user  wishes  to  change). 

P62:  Ask  the  user  for  E3  (new  preferred  time  use  code  (CT11)) 

for  the  time  slot  identified  in  P61. 

P63:  Locate  the  time  slot  entered  in  P61  on  the  DS26  data  from 

P3.  Enter  the  CT11  from  P62  onto  the  appropriate  field 
for  this  time  slot. 

P64:  Identify  the  employee  identifier  (ID4)  on  the  0S26  data 

from  P3  for  the  person  for  whom  this  set  of  DS26  data 
provides  weekly  schedule  availability  data. 

P65:  Determine  if  there  are  any  entries  (ID27s)  on  the  DL41 

list  for  the  ID4  from  P64  and  the  ID10  from  Rl.  Yes  = 
P66;  No  =  P14 

P66:  Identify  each  of  the  ID27s  on  the  DL41  list  for  the  ID4 

from  P64  and  the  ID10  from  Rl.  Put  on  a  temporary  list 
cal  led  the  P66  list. 

FN3:  FOR  each  of  the  ID27s  on  the  P66  list: 

P67:  Locate  the  DS27  data  corresponding  to  the  ID27  for  this 

iteration  of  FN3, 

FN3.1:  FOR  each  day  of  the  month  on  the  DS27  data  from  P67  (or 
the  day  of  the  month  identified  in  P88,  if  any): 

P68:  Identify  the  day  of  the  week  for  this  day  of  the  month. 

Is  it  the  same  as  the  day  of  the  week  from  P4?  Yes  =  P69 
No  =  P89  (next  FN3.1) 

P69:  Identify  the  time  slot  (1-96)  on  the  DS27  data  from  P67 

for  the  day  of  the  month  for  this  iteration  of  FN3.1  that 
is  the  same  as  the  time  slot  entered  in  P61. 

P70:  Identify  the  current  preferred  time  use  code  (CT11)  for 

the  time  slot  identified  in  P69  as  shown  on  the  DS27  data 
located  in  P67  for  the  time  slot.  Store  this  CT11. 

P71:  Fill  in  the  time  slot  identified  in  P69  on  the  DS27  data 

from  P67  for  the  question  about  preferred  time  use  with 
the  CT11  code  entered  in  P62. 

P 72 :  Is  there  a  task  currently  scheduled  in  the  time  slot 

identified  in  P69?  Yes  =  P73;  No  =  P86 
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P73:  Identify  the  task  identifier  (ID23)  for  the  task  that  is 

scheduled  in  the  time  slot  identified  in  P69. 

P74:  Locate  the  DS24  data  corresponding  to  the  ID23  from  P73. 

P75:  Is  the  current  answer  shown  on  the  DS24  data  from  P74  to 

the  question  as  to  whether  all  of  the  time  slots  for  the 
tasks  identified  in  P73  are  scheduled  in  the  correct  time 
use  code  a  ‘Yes'  or  ’No’?  Yes  =  P76;  No  =  P78 

P76:  Enter  the  answer  ‘No1  on  the  DS24  data  from  P74  for  the 

question  as  to  whether  the  task  is  scheduled  in  the 
correct  time  use. 

P77:  GO  TO  P86. 

P78:  Using  the  0S24  data  from  P74,  identify  the  time  use  code 

(CT11)  for  the  task  (not  the  time  slot)  identified  in 
P73.  Is  this  time  use  code  the  same  as  the  time  use  code 
from  P7U  (i.e.,  was  this  time  slot  previously  scheduled  in 
the  correct  preferred  time  use)?  Yes  =  P86;  No  =  P79 

P79:  Is  the  time  use  code  (CT11)  identified  in  P78  the  same  as 

the  CT11  entered  in  P62?  Yes  =  P80;  No  =  P86 

P80:  Using  the  0S24  data  from  P74,  identify  the  time  slot 

information  for  the  start  time  of  the  task  identified  in 
P73. 

P81 :  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (1027)  that  is  part  (1)  of  the  time  slot 
information  located  in  P80. 

FN3.1.1:  FOR  each  time  slot  in  which  the  task  identified  in  P73 
is  currently  scheduled,  beginning  with  the  start  time  slot 
identified  in  P80  and  the  DS27  data  from  P81: 

P82:  Locate  the  time  slot  for  this  iteration  of  FN 3.1.1. 

(Follow  the  instructions  in  P15  of  Step  F4B-1.) 

P83:  Using  the  0S27  data  for  this  iteration  of  FN3.1.1, 

determine  if  the  time  slot  for  this  iteration  of  FN 3.1.1 
was  scheduled  in  the  correct  preferred  time  use.  Yes  = 
P84;  No  =  P86 

P84:  NEXT  FN3.1.1,  end  of  FN3.1.1,  GO  TO  P85. 

P85:  Enter  the  answer  'Yes*  on  the  DS24  data  from  P74  for  the 

question  as  to  whether  the  task  identified  in  P73  is 
scheduled  in  the  correct  time  use. 
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P86:  Derive  the  sum  that  is  equal  to  the  day  of  the  month  for 

this  iteration  of  FN3.1,  plus  '7‘. 

P87:  Is  there  a  day  of  the  month  on  the  DS27  data  from  P67  that 

is  equal  to  the  value  derived  in  P86?  Yes  =  P88;  No  =  P90 
(next  FN3) 

P88:  Identify  the  day  of  the  month  on  the  DS27  data  from  P67 

with  the  value  derived  in  P86.  Store  this  date. 

P89:  NEXT  FN3.1.  end  of  FN3.1,  GO  TO  P90. 

P90:  NEXT  FN3;  end  of  FN3,  GO  TO  P14. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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In  this  Step,  the  program  identifies  the  tasks  that  need  to  be 
rescheduled  due  to  a  change  in  the  availability  for  scheduling 
information  given  on  the  monthly  schedule  data  (DS27).  It  also  allows 
the  user  to  enter  changes  in  preferred  time  use  (CT11)  on  the  DS27 
data. 

PREVIOUS  STEP:  None;  initiated  by  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 


Menu  Selection  and  Input  Sequence: 

SI: 

7  (scheduling  data) 

S2: 

3  (monthly  schedule  data) 

S3: 

2  (change  monthly  schedule  data) 

Ql: 

Monthly  schedule  identifier  (ID27)  for  the  monthly 
schedule  data  (0S27)  that  the  user  wishes  to  change. 
Query  is  in  P2. 

Q2: 

Day  of  the  month  (1-31)  that  the  user  wishes  to 
change.  Query  is  in  P4. 

Q3: 

Whether  the  user  wishes  to  change  scheduling 
availability  information  or  preferred  time  use 
information.  Query  is  in  P5. 

El: 

Whether  an  entire  day  has  any  time  slots  available 
for  scheduling.  Entry  is  in  P7. 

Q4: 

Time  slot  number  (1-96)  that  user  wishes  to  change. 
Query  is  in  P9  and  P30. 

E2: 

Whether  the  time  slot  is  available  for  scheduling. 
Entry  is  in  Pll. 

E3: 

Preferred  time  use  code  (CT11).  Entry  is  in  P34. 

Data  Retrievals: 

Rl: 

OHMIS  service  area  identifier  (ID10)  for  the  user 
executing  Step  F4B-5.  From  P5  of  Step  F1A-2. 

0S24: 

Specific  task  scheduling  data 

DS27 : 

Monthly  schedule  data  (availability  and  use) 
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PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

PI:  Start  a  list,  called  the  PI  list.  This  will  be  a  list  of 

the  task  identifier  (ID23)  for  the  tasks  that  need  to  be 
rescheduled. 

P2:  Ask  the  user  for  Q1  (monthly  schedule  identifier  (ID27) 

for  the  DS27  data  that  the  user  wishes  to  change). 

P3:  Locate  the  DS27  data  corresponding  to  the  ID27  entered  in 

P2. 

P4:  Ask  user  for  Q2  (day  of  the  month  (1-31)  that  the  user 

wishes  to  change). 

P5:  Ask  user  for  Q3  (whether  user  wishes  to  change 

availability  information  or  the  preferred  time  use  (CT11) 
code).  Availability  information  =  P6;  CT11  =  P30 

P6:  Ask  user  for  El  (whether  any  of  the  time  slots  on  the  day 

of  the  month  entered  in  P4  are  to  be  available  for 
scheduling).  Yes  =  P7;  No  =  P 9 

P7:  Enter  tne  answer  'No'  in  the  field  corresponding  to  the 

day  of  the  month  obtained  in  P4  on  the  DS27  data  from  P3 
for  the  question  as  to  whether  the  entire  day  has  any  time 
available  for  scheduling.  Also  enter  the  answer  'No'  for 
the  question  about  whether  the  time  slot  is  available  for 
scheduling  in  each  of  the  time  slots  on  the  DS27  data  from 
P3  for  the  day  of  the  month  from  P4. 

P 8:  GO  TO  FN1  (P24). 

P9:  Ask  the  user  for  Q4  (time  slot  number  (1-96)  that  the  user 

wishes  to  change). 

P10:  Ask  user  for  E2  (whether  the  time  slot  is  available  for 

scheduling).  Answers:  Yes/No 

Pll:  Locate  the  time  slot  on  the  DS27  data  from  P3  that  is  for 

the  day  of  the  month  from  P4  and  the  time  slot  number  from 
P9.  Enter  the  answer  given  in  P10  onto  the  0S27  data  for 
the  question  about  availability  for  scheduling  for  this 
time  slot. 

P12:  Was  the  answer  given  in  P10  a  'Yes'  or  a  'No'?  Yes  =  P13; 

No  =  P17 

P 13 :  Ask  the  user  for  Q5  (whether  the  user  has  more  changes  to 
this  set  of  DS27  data).  Yes  =  P4;  No  =  P 1 4 
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P14:  Are  there  any  entries  (ID23s)  on  the  Pi  list?  Yes  =  P15; 

No  =  P 16 

P15 :  GO  TO  PI  of  Step  F4B-2. 

P 16 :  GO  TO  P5  of  Step  F4B-1. 

P 17 :  Check  whether  there  are  any  time  slots  on  the  0S27  data 

from  P3  for  the  day  of  the  month  from  P4  that  have  an 
answer  of  'Yes'.  Yes  =  P 19 ;  No  =  P18 

P18:  Enter  the  answer  ‘No*  for  the  question  about  availability 

for  scheduling  in  the  field  corresponding  to  the  day  of 
the  month  from  P4  on  the  DS27  data  from  P3. 

P19:  Does  the  DS27  data  from  P3  indicate  that  the  time  slot 

located  in  Pll  currently  has  a  task  scheduled  it?  Yes  = 

P 20 ;  No  =  P13 

P20:  Identify  the  task  identifier  (ID23)  for  the  task  scheduled 

in  the  time  slot  located  in  Pll. 

P21:  Is  the  ID23  from  P20  already  on  the  PI  list?  Yes  =  P13; 

No  =  P22 

P22:  Add  the  ID23  from  P20  to  the  PI  list. 

P23:  GO  TO  P13. 

FN1:  FOR  each  time  slot  (1-96)  on  the  DS27  data  from  P3  for 

the  day  of  the  month  located  in  P4: 

P24:  Locate  the  time  slot  corresponding  to  this  iteration  of 

FNl. 

P25:  Does  the  DS27  data  from  P3  indicate  that  the  time  slot 

located  in  P24  currently  has  a  task  scheduled  in  it?  Yes 
=  P26:  No  =  P29  (next  FNl) 

P26:  Identify  the  task  identifier  (ID23)  of  the  task  scheduled 

in  the  time  slot  located  in  P24. 

P27:  Is  the  ID23  from  P26  already  on  the  PI  list?  Yes  =  P29 

(next  FNl);  No  =  P 28 

P28:  Add  the  ID23  from  P26  to  the  PI  list. 

P29:  NEXT  FNl;  end  of  FNl,  GO  TO  P13. 

P30:  (From  P5):  Ask  the  user  for  Q4  (time  slot  number  (1-96) 

that  the  user  wishes  to  change). 
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P31 :  Ask  the  user  for  E3  (new  preferred  time  use  code  (CT11)). 

P32:  Locate  the  time  slot  entered  in  P3Q  on  the  DS27  data  from 

P3. 

P33:  Identify  the  current  preferred  time  use  code  (CTll)  for 

the  time  slot  located  in  P32  as  shown  on  the  DS27  data  for 
this  time  slot.  Store  this  value. 

P34:  Enter  the  CTll  from  P31  onto  the  appropriate  field  for 

this  time  slot. 

P35:  Is  there  a  task  currently  scheduled  in  the  time  slot 

identified  in  P 30?  Yes  =  P36;  No  =  P13 

P36:  Identify  the  task  identifier  (ID23)  for  the  task  chat  is 

scheduled  in  the  time  slot  identified  in  P30. 

P37:  Locate  the  0S24  data  corresponding  to  the  ID23  from  P36. 

P38:  Is  the  current  answer  shown  on  the  DS24  data  from  P37  to 

the  question  as  to  whether  all  of  the  time  slots  for  the 
task  identified  in  P36  are  scheduled  in  the  correct  time 
use  code  a  'Yes'  or  a  'No'?  Yes  =  P39;  No  =  P41 

P39:  Enter  the  answer  'No'  on  the  DS24  data  on  P37  for  the 

question  as  to  whether  the  task  is  scheduled  in  correct 
time  use. 

P4U:  GO  TO  P13. 

P41:  Using  the  0S24  data  from  P37,  identify  the  time  use  code 

(CTll)  for  the  task  (not  the  time  slot)  identified  in 
P30.  Is  this  CTll  the  same  as  the  same  CTll  identified  in 
P33?  Yes  =  P13;  No  =  P42 

P42:  Is  the  CTll  identified  in  P41  the  same  as  the  CTll 

identified  in  P31?  Yes  =  P43;  No  =  P13 

P43:  Using  the  0S24  data  from  P37,  identify  the  time  slot 

information  for  the  start  time  slot  of  the  task  identified 
in  P36. 

P44:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (1027)  that  is  part  (1)  of  the  time  slot 
information  located  in  P43.  (Note:  This  will  not 
necessarily  be  the  same  as  the  0S27  data  located  in  P3,  if 
the  task  identified  in  P36  is  scheduled  for  days  involving 
more  than  one  month.) 
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FN2:  FOR  each  time  slot  in  which  the  task  identified  in  P36  is 

currently  scheduled,  beginning  with  the  start  time  slot 
identified  in  P43  and  the  DS27  data  from  P44: 

P45:  Locate  the  time  slot  for  this  iteration  of  FN2.  (Follow 

the  instructions  in  P15  of  Step  F4B-1.) 

P46:  Using  the  OS27  data  for  this  iteration  of  FN2,  determine 

if  the  time  slot  for  this  iteration  FN2  was  scheduled  in 
the  correct  preferred  time  use.  Yes  =  P47;  No  =  P13 

P47:  NEXT  FN2;  end  of  FN2,  GO  TO  P48. 

P48:  Enter  the  answer  ‘Yes'  onto  the  DS24  data  from  P37  for  the 

question  as  to  whether  the  task  identified  in  P36  is 
scheduled  in  the  correct  time  use. 

P49:  GO  TO  P13. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS:  None 
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In  this  Step,  the  program  allows  the  user  to  enter  changes  to  the 
specific  task  scheduling  data  (0S24)  and  determines  whether  that  task 
described  on  the  DS24  data  needs  to  be  rescheduled  because  of  the 
changes  made  to  the  DS24  data.  The  program  also  makes  the  changes  to 
the  monthly  schedule  data  (0S27)  corresponding  to  the  changes  made  on 
the  0S24  data 

PREVIOUS  STEP:  None;  initiated  by  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

Si:  7  (scheduling  data) 

S2:  4  (specific  task  scheduling  data) 

S3:  1  (change  selected  items  on  the  specific  task 

scheduling  data) 

Ql:  Task  identifier  (ID23)  for  the  task  that  the  user 

wishes  to  change.  Query  is  in  P2. 

Q2:  The  data  element  that  the  user  wishes  to  change. 

Query  is  in  P4. 

Q3:  Whether  user  wishes  to  make  any  additional  changes. 

Query  is  in  P6. 

El:  Entry  of  changes  to  one  of  the  five  data  elements  the 

changes  to  which  do  not  affect  the  scheduling  to  the 
task  (see  P4).  Query  is  in  P5. 

E2:  New  number  of  user  specified  time  slots  required  to 

complete  the  task.  Entry  is  in  P12. 

Q4:  Whether  the  user  wishes  to  add,  delete  or  change  the 

special  restrictions  dates  for  the  scheduling  of  the 
task.  Query  is  in  P66. 

Q5:  Which  (number  from  *1'  to  *3')  of  the  special 

restrictions  dates  already  listed  on  the  DS24  data 
the  user  would  like  to  change  or  delete.  Query  is  in 
P67  and  P96. 

E3:  New  special  restrictions  date  or  range  of  special 

restrictions  dates.  Query  is  in  P74  and  P97. 

Data  Retrievals: 
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DS24:  Specific  task  scheduling  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop)) : 

Pi:  Start  a  list,  called  the  PI  list.  This  list  will  contain 

the  one  task  identifier  (ID23)  for  the  task  that  is  being 
changed  in  Step  F4B-6  (i.e.,  the  ID23  from  P2),  if  the 
changes  made  to  the  DS24  data  as  a  part  of  Step  F4B-6 
result  in  the  need  to  reschedule  the  task. 

P2:  Ask  the  user  for  Q1  (task  identifier  (ID23)  of  the  task 

that  the  user  wishes  to  change). 

P3:  Locate  the  DS24  data  corresponding  to  the  ID23  from  P2. 

P4:  Ask  the  user  for  Q2  (what  part  of  the  task  data  (DS24)  the 

user  wishes  to  change).  Supplement  to  the  detailed 
description  of  the  task  =  P5;  Supplement  to  the 
description  of  the  task  given  on  the  Scheduling  Notice 
(015)  =  P5;  Supplement  to  the  description  given  to  a 
participant  in  the  task  =  P5;  Supplement  to  the 
description  of  the  preparation  for  the  task  =  P5;  Facility 
identifier  (ID8)  for  the  task  =  P5;  User  specified  number 
of  time  slots  =  PlO;  Erase  the  weekly  schedule  identifier 
(ID28)  identifying  standard  restrictions  for  scheduling 
the  task  =  P54;  Additions  or  changes  to  the  restricted 
dates,  i.e.,  to  the  special  restrictions  =  P66 

P5:  Ask  user  for  El  (i.e.,  the  new  (changed)  information  on 

the  data  element  selected  in  P4.  Enter  this  new 
information  onto  the  DS24  data  located  in  P3. 

P6:  Ask  the  user  for  Q3  (whether  the  user  wishes  to  make  any 

additional  changes  to  this  task).  Yes  =  P4;  No  =  P7 

P7:  Are  there  any  entries  on  the  Pi  list?  Yes  =  P8;  No  =  P9 

P8:  GO  TO  PI  of  Step  F4B-2. 

P9:  GO  TO  P5  of  Step  F48-1. 

PlO:  Ask  the  user  for  E2  (new  number  of  user  specified  time 

slots  required  to  complete  the  task). 

Pll:  Is  the  task  identified  in  P2  shown  to  be  currently 

scheduled?  Yes  =  P14;  No  =  P12 

P12:  Enter  the  value  from  PlO  onto  the  DS24  data  located  in  P3 

for  the  field  for  the  user  specified  number  of  required 
time  slots  to  complete  the  task. 
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P13 :  GO  TO  P6. 

P 14 :  Identify  the  current  value  for  a  number  of  user 

specified  time  slots  on  the  DS24  data  from  P3.  (Note: 

This  value  is  the  same  as  the  standard  required  time 
slots,  if  the  user  has  not  previously  specified  the  time 
slots  required  to  complete  the  task  for  this  value.) 

P15:  Put  the  new  user  specified  required  number  of  time  slots 

(from  P10)  onto  the  DS24  data  from  P3. 

P16 :  Is  the  value  in  P10  less  than  or  greater  than  the  value  in 

P14.  Less  than  =  P20;  Greater  than  =  P17 

PI 7 :  Determine  if  the  ID23  from  P2  is  already  on  the  PI  list. 

Yes  =  P6;  No  =  P18 

P18:  Put  the  ID23  from  P2  onto  the  PI  list. 

P19:  GO  TO  P6. 

P20:  Using  the  DS24  data  from  P3,  identify  the  time  slot 

information  for  the  start  time  slot  in  which  the  task  is 
scheduled. 

P21 :  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (ID27)  in  part  (1)  of  the  start  time  slot 
identified  in  P20. 

FNl:  FOR  each  time  slot  in  which  the  task  from  P2  is  currently 

scheduled,  beginning  with  the  start  time  slot  identified 
in  P20  in  the  DS27  data  located  in  P21 : 

P22:  Locate  the  time  slot  for  this  iteration  of  FNl.  (Follow 

the  instructions  given  in  P15  of  Step  F4B-1.) 

P23:  Using  the  DS27  data  for  this  iteration  of  FNl,  identify 

the  cumulative  number  of  time  slots  scheduled  for  the  task 
as  of  the  time  slot  for  this  iteration  of  FNl. 

P24:  Using  the  DS27  data  for  this  iteration  of  FNl,  identify 

the  cumulative  number  of  interruptions  as  of  the  time 
slot  for  this  iteration  of  FNl. 

P25:  Derive  the  value  that  is  equal  to  the  value  from  P23  minus 

the  value  from  P24. 

P26:  Is  the  value  derived  in  P25  equal  to  the  value  specified 

in  PIG?  Yes  =  P28;  No  =  P27  (next  FNl) 

P27:  NEXT  FNl.  (Note:  The  end  of  FNl  will  never  be  reached.) 
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P28:  Store  the  value  obtained  in  P23  for  the  last  iteration  of 

FNl . 

P29:  Enter  the  value  from  P24  from  the  last  iteration  of  FNl 

onto  the  0S24  data  located  in  P3  as  the  total  number  of 
interruptions  in  the  scheduling  of  the  task. 

P3Q:  Store  the  time  slot  information  (i.e.,  ID27,  date  and  time 

slot  number)  for  the  time  slot  reached  in  the  last 
iteration  of  FNl. 

P31 :  Place  the  time  slot  information  stored  in  P30  onto  the 

0S24  data  located  in  P3  as  the  end  time  slot  for  the 
scheduling  of  the  task. 

P32:  Determine  if  there  is  a  due  date  for  the  task  identified 

in  P2.  This  is  shown  on  the  DS24  data  from  P3.  Yes  = 

P33;  No  »  FN2  (P38) 

P33:  Identify  the  due  date  for  the  task  identified  in  P2  as 

shown  on  the  DS24  data  from  P3. 

P34:  Is  the  date  identified  in  P3  later  than  the  date  stored  in 

P30?  Yes  =  FN2  (P38);  No  =  P35 

P35:  Enter  the  answer  'Yes*  on  the  DS24  data  from  P3  for  the 

question  as  to  whether  the  task  was  scheduled  after  the 
due  date. 

P36:  Skip  this  step. 

P37:  Skip  this  step. 

FN2:  FOR  each  time  slot  in  which  the  task  from  P2  is  currently 

scheduled,  beginning  with  the  start  time  slot  identified 
in  P20  and  the  DS27  data  located  in  P21: 

P38:  Locate  the  time  slot  for  this  iteration  of  FN2.  (Follow 

the  instructions  given  in  P15  of  Step  F46-1.  Use  the  time 
slot  information  identified  in  P41  or  P48  to  identify  the 
next  time  slot  for  those  iterations  of  FN2  that  involve 
erasing  the  information  about  the  next  time  slot,  i.e., 
those  iterations  of  time  slots  equal  to  or  later  than  the 
time  slot  stored  in  P30.) 

P39:  Is  the  time  slot  located  in  P38  equal  to,  earlier  than  or 

later  than  the  time  slot  stored  in  P30?  (Note:  To 
determine  this,  obtain  the  year  and  month  for  the  two 
dates  by  locating  the  OS27  data  corresponding  to  the  ID27 
that  is  part  (1)  of  the  time  slot  information  and  then 
compare  the  two  years,  months  and  the  dates  and  time  slot 
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numbers.)  Equal  to  =  P30;  Earlier  than  =  P43;  Later  than 
=  P48 

P40:  Change  the  answer  to  the  question  about  whether  the 

scheduling  continues  shown  on  the  time  slots  of  this 
iteration  of  FN2  to  be  'No'. 

P41 :  Identify  and  store  the  information  on  the  time  slot  in 

this  iteration  of  FN2  about  the  next  time  slot  in  which 
the  task  from  P2  is  currently  scheduled. 

P42:  Erase  the  information  on  the  time  slot  for  this  iteration 

of  FN2  about  the  next  time  slot  in  which  the  task  from  P2 
is  currently  scheduled. 

P43:  Using  the  DS27  data  for  this  iteration  of  FN2,  compare  the 

preferred  time  use  code  (CT11)  for  the  time  slot  with 
the  actual  time  use  code  for  the  task.  Are  they  the 
same?  Yes  =  P45;  No  =  P44 

P44:  Generate  a  flag,  called  the  P44  flag.  This  flag  indicates 

that  at  least  one  of  the  time  slots  scheduled  for  the  task 
identified  in  P2  is  scheduled  in  a  time  slot  that  is  not 
the  correct  preferred  time  use.  (If  this  flag  has  already 
been  generated,  skip  P44.) 

P45:  Enter  the  value  entered  in  P10  onto  the  appropriate  field 

for  the  time  slot  in  this  iteration  of  FN2  (onto  the  time 
slot  on  the  DS27  data)  for  the  answer  to  the  question 
about  the  number  of  user  specified  time  slots  required  to 
complete  the  task. 

P46:  Enter  the  value  stored  in  P28  onto  the  appropriate  field 

for  the  time  slot  for  this  iteration  of  FN2  (i.e.,  onto 
the  DS27  data  time  slot)  for  the  answer  to  the  question 
about  the  actual  time  slots  scheduled  for  the  task. 

P47 :  GO  TO  P50  (next  FN2). 

P48:  Identify  and  store  the  information  on  the  time  slot  for 

this  iteration  of  FN2  about  the  next  time  slot  in  which 
the  task  from  P2  is  currently  scheduled. 

P49:  Erase  all  of  the  scheduling  information  for  the  time  slot 

for  this  iteration  of  FN?  (i.e.,  for  the  time  slot  on  the 
DS27  data);  i.e.,  erase  the  task  identifier  (ID23)  for  the 
task  previously  scheduled  in  this  time  slot  (i.e.,  the 
1023  from  P2)  and  all  of  the  information  about  the 
scheduling  of  the  task  contained  in  this  time  slot. 


P50 :  NEXT  FN2 ;  end  of  FN2 ,  GO  TO  P51 . 
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P51:  Is  there  a  flag  in  P44?  Yes  =  P52;  No  =  P12 

P52:  Enter  the  answer  of  'No'  onto  the  DS24  data  from  P3  for 

the  question  as  to  whether  all  of  the  time  slots  for  the 
task  identified  in  P2  are  scheduled  in  the  preferred  time 
use. 

P53 :  GO  TO  P12. 

P54:  (From  P4):  (Note:  The  user  has  elected  in  P5  to  erase 

the  weekly  schedule  identifier  (ID28)  identifying  the 
weekly  schedule  data  (DS26)  that  provides  the  standard 
restrictions  to  the  scheduling  of  al 1  tasks  involving 
the  participant  (i.e.,  the  requirement  implementation 
unit)  in  the  scheduling  of  the  task  identified  in  P2. 

This  means  that  the  user  wishes  those  restrictions  to  be 
waived  for  the  task  identified  in  P2  only.  If  the 
restrictions  shown  on  the  DS26  data  identified  by  the  ID28 
currently  on  the  DS24  data  located  in  P3  do  not  apply  to 
the  participant  any  more  (i.e.,  they  do  not  apply  for  any 
tasks  scheduled  for  this  participant),  then  the  ID28 
should  be  changed  on  the  contact  and  location  data  (DS28) 
for  that  participant.  If  the  user  wishes  to  add  an  ID28 
(i.e.,  add  standard  restrictions)  for  the  participant, 
this  should  be  done  by  adding  the  ID28  to  the  DS28  data 
(i.e.,  to  the  data  on  the  participant)  and  not  by  adding 
it  to  the  DS24  data  (i.e.,  not  by  adding  it  to  the  data  on 
the  task).  This  would  be  done  in  Step  F4B-1.  Thus,  the 
only  change  the  user  can  make  in  Step  F4B-6  to  the  ID28 
information  on  the  0524  data  is  to  erase  the  ID28 
information.)  Erase  the  1028  from  the  DS24  data  located 
in  P3. 

P55:  Identify  the  answer  to  the  question  on  the  DS24  data  from 

P3  as  to  whether  the  restrictions  on  the  scheduling  of  the 
task  identified  in  P2  are  standard  restrictions  or  are 
both  types  of  restrictions.  (Note:  The  question  could 
not  be  answered  as  ‘special  restrictions'  (i.e.,  no 
standard  restrictions),  as  there  would  have  been  no  ID28 
to  have  erased,  if  there  had  been  no  standard 
restrictions.)  Standard  restrictions  =  P56;  Both  types  of 
restrictions  =  P59 

P56:  Change  the  answer  on  the  DS24  data  located  in  P3  for  the 

question  as  to  whether  there  are  any  restrictions  on  the 
scheduling  of  the  task  identified  in  P2  to  be  'No'. 

P57:  Erase  the  answer  on  the  DS24  data  located  in  P3  for  the 

question  about  the  type  of  restrictions  on  the  scheduling 
of  the  task  identified  in  P2. 

Pb8:  GO  TO  P60. 
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P59:  Change  the  answer  on  the  DS24  data  located  in  P3  for  the 

question  about  the  type  of  restrictions  on  the  scheduling 
of  the  task  identified  in  P2  to  be  ‘special  restrictions' 
(i.e.,  not  'both  types  of  restrictions'). 

P60:  Determine  from  the  DS24  data  located  in  P3  whether  the 

task  identified  in  P2  is  currently  scheduled.  Yes  =  P61 ; 
No  =  P6 

P61 :  Identify  the  time  slot  information  on  the  DS24  data  from 

P3  for  the  time  that  this  task  is  scheduled  to  start. 

P62:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 

identifier  (1027)  that  is  part  (1)  of  the  time  slot 
information  identified  in  P6I . 

FN3:  Fuk  each  time  slot  in  which  the  task  identified  in  P2  is 

currently  scheduled,  beginning  with  the  time  slot 
identified  in  P61  and  the  DS27  data  from  P62: 

P63:  Locate  the  time  slot  for  this  iteration  of  FN3.  (Follow 

the  instructions  given  in  P15  of  Step  F4B-6.) 

P64:  Change  the  answer  to  the  questions  on  the  DS27  data  time 

slot  located  in  P63  about  whether  there  are  any 
restrictions  on  the  scheduling  of  the  task,  and,  if  so, 
what  types  of  restrictions,  to  be  the  current  answers  on 
the  DS24  data  from  P3. 

P65:  NEXT  FN3;  end  of  FN3 ,  GO  TO  P6. 

P66:  (From  P4):  Ask  the  user  for  1)4  (whether  the  user  wishes 

to  add,  delete  or  change  special  restrictions  dates).  Add 
=  P73;  Delete  =  P67;  Change  =  P96 

Pb 7 :  Ask  the  user  for  05  (number  from  '1'  to  '3'  identifying 

which  of  the  three  special  restriction  dates  or  ranges  of 
dates  the  user  wishes  to  delete).  (Note:  There  can  be  up 
to  3  dates  or  3  ranges  of  dates  on  the  DS24  data  showing 
the  special  restriction  dates  for  the  scheduling  of  this 
task. ) 

P68:  Identify  the  special  restriction  date  or  range  of  dates  on 

the  DS24  data  from  P3  that  the  user  specified  in  P67. 

Erase  ttiis  special  restriction  date  from  the  DS24  data 
located  in  P3. 

P69:  Determine  from  the  DS24  data  located  in  P3  whether  there 

are  now  any  special  restriction  dates  on  the  DS24  data. 

Yes  =  P6;  No  =  P70 
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P 70:  Identify  the  answer  to  the  question  on  the  DS24  data  from 

P3  as  to  whether  the  restrictions  on  the  scheduling  of  the 
task  identified  in  P2  is  'special  restrictions'  or  'both 
types  of  restrictions'  (standard  and  special).  Special 
restrictions  =  P56;  Both  =  P7I 

P71:  Change  the  answer  on  the  DS24  data  located  in  P3  for  the 

question  about  the  type  of  restrictions  on  the  scheduling 
of  the  task  identified  in  P2  to  be  1  standard 
restrictions ' . 

P72 :  GO  TO  P60. 

P 73 :  Determine  the  number  of  special  restriction  dates  or 

ranges  of  dates  that  are  currently  on  the  DS24  data 
located  in  P3,  i.e.,  'O',  '1'  or  '2'.  Store  this  value. 
(Note:  If  the  answer  is  '3',  tell  the  user  that  no  more 
special  restriction  dates  can  be  added  before  some  of  the 
existiny  special  restriction  dates  have  been  deleted.) 

P74:  Ask  the  user  for  E3  (one  of  the  new  special  restriction 

dates  or  ranges  of  dates  the  user  wishes  to  add).  Enter 
this  date  or  range  of  dates  onto  the  DS24  data  located  in 
P3. 

P 76 :  Was  the  answer  in  P73  a  'O'?  Yes  =  P76;  No  =  P81 

P 76 :  Determine  whether  the  answer  on  the  DS24  data  from  P3  to 

the  question  about  whether  there  are  any  restrictions  on 
the  scheduling  of  the  task  identified  in  P2  is  'Yes'  or 
'No' .  Yes  =  P77 ;  No  =  P79 

P77:  Change  the  answer  on  the  DS24  data  located  in  P3  to  the 

question  about  the  type  of  restrictions  on  the  scheduling 
of  the  task  identified  in  P2  to  be  'both'  (types  of 
restrictions ) . 

P78:  GO  TO  P81. 

P 79 :  Change  he  answer  on  the  DS24  data  located  in  P3  for  the 

question  as  to  whether  there  are  any  restrictions  on  the 
scheduling  of  the  task  identified  in  P2  to  be  'Yes'. 

P80:  Fill  the  answer  on  the  DS24  data  located  in  P3  for  the 

question  as  to  tne  types  of  restrictions  to  the  scheduling 
of  the  task  to  be  'special  restrictions ' . 

P81:  Determine  from  the  DS24  data  located  in  P3  whether  the 

task  identified  in  P2  is  currently  scheduled.  Yes  =  P82; 
No  =  P6 
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P82 :  Identify  the  time  slot  information  on  the  DS24  data  from 

P3  for  the  time  slot  that  the  task  identified  in  P2  is 
scheduled  to  start. 

P83:  Identify  the  time  slot  information  on  the  DS24  data  from 

P3  for  the  time  slot  that  the  task  identified  in  P2  is 
scheduled  to  end. 

P84:  Determine  what  format  was  used  to  add  (or  change)  the 

special  restriction  dates  entered  n  £3  (as  added  in  P 74 
or  changed  in  P97).  Was  the  format  of  the  special 
restriction  dates:  (1)  equal  to  ’X';  (2)  greater  than  1 X ' 
and  less  than  ' Y ' ;  (3)  less  than  'X'  and  greater  than  ' Y ' ; 
(4)  less  than  'X';  or,  (5)  greater  than  1 Y *  (where  'X'  and 
1 Y 1  are  dates  and  'less  than'  means  before  and  ‘greater 
than'  means  after  a  date)?  1  =  P85;  2  =  P87;  3  =  P90;  4  = 
P92 ;  5  =  P93 

P85:  Is  tne  date  that  is  part  (2)  of  the  start  time  slot 

information  identified  in  P82  equal  to,  less  than  or 
greater  than  the  date  entered  as  E3?  Equal  to  =  P17;  Less 
than  =  P86;  Greater  than  =  P94 

P86 :  Is  the  date  that  is  part  (2)  of  the  end  time  slot 

information  identified  in  P83  equal  to,,  less  than  or 
greater  than  the  date  entered  as  E3?  Equal  to  =  P17;  Less 
than  =  P94 ;  Greater  than  =  P17 

P87 :  Is  the  date  that  is  part  (2)  of  the  start  time  slot 

information  identified  in  P82  equal  to,  less  than  or 
greater  than  the  'X'  date  for  the  range  of  dates  entered 
as  E3?  Equal  to  =  Pi.7;  Less  than  =  P88;  Greater  than  = 

P89 

P88:  Is  the  date  that  is  part  (2)  of  the  end  time  slot 

identified  in  P83  equal  to,  less  than  or  greater  than  the 
'X'  date  for  the  range  of  dates  entered  as  E3?  Equal  to  = 
P17;  Less  than  =  P94;  Greater  than  =  P17 

P89:  Is  the  date  that  is  part  (2)  of  the  start  time  slot 

identified  in  P82  equal  to,  less  than  or  greater  than  the 
* Y *  date  for  the  range  of  dates  entered  as  E3?  Equal  to  = 
P17;  Less  than  =  Pi 7 ;  Greater  than  =  P94 

P90:  Is  the  date  that  is  part  (2)  of  the  start  time  slot 

identified  in  P82  equal  to,  less  than  or  greater  than  the 
'X'  date  for  the  range  of  dates  entered  as  E3?  Equal  to  = 
P17;  Less  than  =  P 17 ;  Greater  than  =  P91 

P9I :  Is  the  date  that  is  part  (2)  of  the  time  slot  identified 

in  P83  equal  to,  less  than  or  greater  than  the  ' Y '  date  of 
the  range  of  dates  entered  as  E3?  Equal  to  =  P17;  Less 
than  =  P 94 ;  Greater  than  =  °17 
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P92:  Is  the  date  that  is  part  (2)  of  the  start  time  slot 

identified  in  P82  equal  to,  less  than  or  greater  than  the 
date  entered  as  E3?  Equal  to  -  P17;  Less  than  =  P17; 
Greater  than  =  P94 

P93:  Is  the  date  that  is  part  (2)  of  the  start  time  slot 

identified  in  P82  equal  to,  less  than  or  greater  than  the 
date  entered  as  E3?  Equal  to  =  P17;  Less  than  =  P94; 
Greater  than  =  P17 

P 94 :  Was  the  answer  given  in  P66  to  add  special  restrictions 

dates  or  to  change  these  dates?  Add  =  P95;  Change  =  P96 

P95:  Was  the  answer  given  in  P75  a  ‘Yes'  or  a  'No'?  Yes  =  P60; 

No  =  P6 

P96:  Ask  the  user  for  Q5  (number  from  '1'  to  ‘ 3 '  indicating 

which  of  the  3  special  restriction  dates  the  user  wishes 
to  change). 

P97:  Ask  the  user  for  E3  (the  new  special  restriction  date  or 

range  of  dates  that  the  user  wishes  to  indicate  is  the 
changed  special  restriction  date). 

P98:  Identify  the  special  restriction  date  on  the  DS24  data 

from  P3  that  the  user  specified  in  P96.  Erase  the  current 
date  in  that  field  and  replace  it  with  the  date  entered  in 
P97 . 

P99:  GO  TO  P81. 

OUTPUT S  AND  GENERATION  OF  DATA  SETS:  None 
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In  this  Step,  the  user  is  allowed  to  specify  the  scheduling  of  a 
task.  The  OHMIS  scheduling  program  (Function  F4A)  automatically 
schedules  tasks  as  they  are  identified  (i.e.,  as  they  are  triggered  by 
requirements)  according  to  a  particular  set  of  scheduling  selection 
criteria.  However,  the  user  may  specify  the  scheduling  of  a 
particular  task  to  fit  particular  needs  and  this  is  done  in  Step 
F4B-7.  This  is  considered  rescheduling,  because,  in  most  cases,  the 
task  will  have  already  been  scheduled  in  the  automatic  OHMIS 
scheduling  program.  In  specifying  the  scheduling  for  a  task,  the  user 
may  override  most  of  the  scheduling  criteria  used  in  the  automatic 
scheduling  of  the  tasks,  such  as  the  criteria  about  interruptions  in 
the  normal  scheduling  of  tasks.  However,  three  criteria  cannot  be 
overridden:  (1)  The  task  must  be  scheduled  to  be  performed  by  a 
person  shown  as  qualified  to  perform  that  type  of  task;  (2)  the  person 
being  scheduled  to  perform  the  task  must  have  the  time  slots  the  user 
specifies  for  scheduling  the  task  shown  as  available  for  scheduling; 
and,  (3)  only  one  primary  person  can  be  scheduled  to  perform  a  task, 
that  is,  the  time  required  to  perform  a  task  cannot  be  split  among 
several  persons  to  perform  it. 

The  third  criteria  above  is  adhered  to  because  it  is  deemed  as 
undesirable  to  allow  scheduling  for  a  task  that  would  have  one  person 
begin  a  task  and  another  person  finish  it.  Tasks  are  always 
scheduled  to  have  one  person  perform  them  from  start  to  finish.  If 
they  are  not  completed,  then  the  remaining  time  to  complete  the  task 
(shown  by  changing  the  user  specified  hours  required  to  complete  the 
task  to  reflect  the  remaining  hours  needed)  is  treated  as  though  it 
was  the  entire  task,  when  the  uncompleted  task  is  rescheduled.  At 
that  time,  the  task  may  be  scheduled  to  be  completed  by  a  person  other 
than  the  person  who  began  the  task.  If,  however,  the  nature  of  the 
task  is  such  that  it  requires  more  than  one  person  to  perform  it  (as 
distinguished  from  the  situation  in  which  a  task  could  have  been 
completed  by  one  person,  but  may  not  have  been  finished  by  the  person 
scheduled  to  complete  it),  the  OHMIS  scheduling  program  allows  the 
user  to  specify  that  additional  persons  should  be  scheduled  to 
perform  the  task  at  the  same  time  that  the  task  has  been  scheduled 
to  be  performed  by  the  other  (primary)  person.  The  specification  for 
additional  persons  to  be  scheduled  to  perform  a  task  is  also  give/i  in 
Step  F46-7.  The  additional  person  that  the  user  specifies  must  also 
be  qualified  to  perform  the  task  and  be  available  for  scheduling  at 
the  time  that  the  task  is  already  scheduled  to  be  performed  by  the 
primary  person. 

Both  the  user  specified  scheduling  of  a  task  or  the  specification  by 
the  user  that  additional  persons  are  to  be  scheduled  to  perform  an 
already  scheduled  task,  may  result  in  the  need  to  reschedule  tasks. 
This  is  because  the  scheduling  specified  by  the  user  will  be  allowed 
to  override  the  scheduling  already  set  up  for  the  performer  of  the 
task,  by  the  OHMIS  automatic  scheduling  program.  That  is,  the  user  is 
allowed  to  specify  that  a  person  be  scheduled  to  perform  a  task  at  a 
time  in  which  the  person  is  already  scheduled  to  perform  another  task. 
Similarly,  if  a  person  is  identified  to  be  an  additional  person  to 
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perform  an  already  scheduled  task,  those  tasks  that  this  person 
already  has  been  scheduled  to  perform  that  are  during  the  same  time 
period  as  the  tasks  that  the  person  is  to  act  as  an  additional 
performer  for  will  need  to  be  rescheduled.  Step  F4B-7  identifies 
those  tasks  that  need  to  be  rescheduled  and  makes  the  necessary 
changes  in  the  specific  task  scheduling  data  (DS24)  and  monthly 
schedule  data  (DS27). 

PREVIOUS  STEP:  None;  initiated  in  the  Menu  Selection  Sequence  shown 
below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence: 

SI:  7  (scheduling  data) 

S2:  4  (specific  task  scheduling  data) 

S3:  4  (rescheduling  a  task) 

Ql:  Task  identifier  (1023)  for  the  task  for  which  the 

user  wishes  to  specify  the  schedule.  Query  is  in  P2. 

Q2:  Whether  user  wishes  to  specify  the  scheduling  for  a 

task  or  to  specify  that  an  additional  person  should 
be  scheduled  to  perform  an  already  scheduled  task. 
Query  is  in  P14. 

Q3:  Employee  identifier  (ID4)  of  the  person  the  user 

would  like  to  schedule  to  perform  the  task.  Query  is 
in  P21. 

Q4:  Year  in  which  the  user  would  like  the  task  scheduled. 

Query  is  in  P32. 

Q5:  Month  in  which  the  user  would  like  the  task 

scheduled.  Query  is  in  P33. 

Q6:  Day  of  the  month  in  which  the  user  would  like  the 

task  scher'  d.  Query  is  in  P47. 

Q7:  Time  slot  number  in  which  the  user  would  like  the 

task  scheduled.  Query  is  in  P48. 

Q8:  Employee  identifier  (ID4)  of  an  additional  person 

the  user  would  like  to  have  perform  a  task.  Query  is 
in  P159. 
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Data  Retrievals: 

Rl:  A  calendar  with  the  number  of  days  in  a  month  for 

each  of  the  months  of  a  year.  This  includes  the 
number  of  days  in  February  for  different  years  (for 
leap  years  and  non-leap  years).  This  calendar  also 
includes  the  day  of  the  week  (Monday  through  Sunday) 
for  each  day  of  the  year.  This  calendar  is  generated 
once  at  the  initiation  of  OHMIS  and  is  used 
thereafter  with  updates  each  year. 

R2:  Current  date 

DS9:  Current  user/position  identity  and  address  data 

DS24:  Specific  task  scheduling  data 

DS26:  Regular  weekly  schedule  availability  data 

DS27:  Monthly  schedule  data  (availability  and  use) 

0L31:  List  of  task  identifiers  (ID23)  for  tasks  that  cannot 
be  scheduled  by  OHMIS  service  area  (ID10) 

0L34:  List  of  qualified  employee  identifiers  (ID4)  by  task 
type  (CT8)  and  by  OHMIS  service  area  (ID10) 

DL35:  List  of  requirement  implementation  identifiers  (ID9) 
for  requirements  having  tasks  that  need  to  be 
scheduled  by  OHMIS  service  area  (ID10) 

0L39:  List  of  task  identifiers  (ID23)  for  tasks  that  need 
to  be  rescheduled  by  OHMIS  service  area  (1010) 

DL40:  List  of  weekly  schedule  identifiers  (ID28)  by 

employee  identifier  (104)  and  by  OHMIS  service  area 
(1010) 

0L41 :  List  of  the  monthly  schedule  identifiers  (1027)  for 
an  OHMIS  service  area  (ID10)  with  the  corresponding 
year  and  month  covered  by  the  monthly  schedule  data 
(DS27)  identified  by  the  ID27  and  the  employee 
identifier  (104)  of  the  employee  performing  the  tasks 
scheduled  on  this  DS27  data 

PROCESSING  (P  =  Process  substep;  FN  =  For  Next  (program  logic 
loop) ) : 

PI:  Start  a  list,  called  the  PI  list.  This  will  be  a  list  of 

the  task  identifiers  (ID23)  of  the  tasks  that  need  to  be 
rescheduled  as  a  result  of  the  user  specifying  the 
schedule  for  the  task  identified  in  P2  (if  any  tasks  need 
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to  be  rescheduled).  (Note:  If  the  user  specifies  a 
schedule  for  the  task  in  P2  that  overlaps  with  the 
existing  schedules  for  another  task,  these  tasks  will  need 
to  be  rescheduled;  the  ID23  for  those  tasks  is  what  is  put 
on  the  PI  list.) 

P2:  Ask  the  user  for  Q1  (task  identifier  (ID23)  for  the  task 

for  which  the  user  wishes  to  specify  the  schedule  or 
wishes  to  reschedule  or  wishes  to  have  an  additional 
performer  of  the  task  scheduled). 

P3:  Locate  the  0S24  data  for  the  ID23  entered  in  P2. 

P4:  Identify  the  OHMIS  service  area  identifier  ( I DIO )  on  this 

set  of  DS24  data. 

P5:  Identify  the  user  specified  number  of  time  slots  required 

to  schedule  the  task  identified  in  P2.  (From  the  DS24 
data  located  in  P3. ) 

P6:  Determine  whether  the  task  identified  in  P2  is  a  dated 

task,  i.e.,  has  a  due  date.  (From  the  DS24  data  located 
in  P3. )  Yes  =  P7;  No  =  P8 

P7:  Identify  the  due  date  for  the  task  identified  in  P2  using 

the  DS24  data  located  in  P3. 

P8:  Determine  whether  the  task  identified  in  P2  is  an 

'employee  transport'  task.  (From  the  DS24  data  located  in 
P3.)  Answers:  Yes/No 

P9:  Determine  the  time  use  code  (CT11)  for  the  task  identified 

in  P2.  (From  the  DS24  data  located  in  P3.) 

P10:  Determine  whether  there  are  any  restrictions  for  the 

scheduling  of  the  task  identified  in  P2  and,  if  so,  what 
type  of  restrictions  (standard,  special  or  both).  If 
there  are  standard  restrictions,  identify  the  weekly 
schedule  identifier  (ID28)  that  provides  the  data  on  these 
restrictions.  Store  this  ID28.  If  there  are  special 
restriction  dates,  identify  these  dates  and  store  them. 
(From  the  DS24  data  located  in  P3.) 

P 11 :  Using  the  DS24  data  from  P3,  identify  the  standard 
number  of  time  slots  required  to  schedule  the  task; 
whether  this  task  was  initiated  based  on  a  Reminder  Notice 
type  of  suspense  data  or  requirements  applicability  data, 
and,  if  based  on  a  requirement,  whether  it  was  a  mandatory 
requirement  or  a  recommendation;  and,  whether  this  task 
requires  a  Scheduling  Notice  (015). 
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P12:  Identify  the  task  type  code  (CT8)  of  the  task  identified 

in  P2.  (From  the  DS24  data  located  in  P3.) 

P13:  Determine  whether  the  task  specified  in  P2  has  already 

been  scheduled,  i.e.,  has  been  'automatically'  scheduled 
by  the  OHMIS  scheduling  program  (Function  F4A).  Yes  = 

P14;  No  =  P15 

P14:  Ask  the  user  for  Q2  (whether  this  execution  of  Step  F4B-7 

is  to  specify  the  scheduling  for  a  task  or  to  specify  that 
an  additional  person  should  be  scheduled  to  perform  an 
already  scheduled  task).  Schedule  (or  reschedule)  a  task 
=  P15;  Additional  person  to  perform  an  already  scheduled 
task  =  P156 

P 15 :  Start  a  counter,  called  the  P15  counter,  with  the  value 

'O'.  This  will  be  a  counter  of  the  number  of  time  slots 
tentatively  scheduled. 

P16:  Start  a  counter,  called  the  P16  counter,  with  the  value  of 

'O'.  This  will  be  a  counter  of  the  number  of  time  slots 
scheduled  since  the  last  interruptions. 

P17:  Start  a  counter,  called  the  PI7  counter,  with  the  value  of 

'O'.  This  will  be  a  counter  of  the  number  of 
interruptions. 

P18:  Start  a  counter,  called  the  P18  counter,  with  the  value  of 

'O'.  This  will  be  the  counter  of  the  number  of  time  slots 
that  are  interruptions. 

P19:  Skip  this  step. 

P20:  Start  a  list,  called  the  P20  list.  Each  entry  on  the  P20 

list  will  have  3  data  elements: 

(1)  A  set  of  time  slot  information.  This  time  slot 
information  will  consist  of  three  parts:  (1)  a 
monthly  schedule  identifier  (1027);  (2)  a  date  of 
the  month  (1-31);  and,  (3)  a  time  slot  number 
(1-96)  indicating  a  quarter  of  an  hour  period 
during  the  day 

(2)  The  value  in  the  P15  counter  as  of  the  scheduling 
of  the  time  slot  identified  in  data  element  (1) 

(3)  The  value  in  the  P17  counter  as  of  the  scheduling 
of  the  time  slot  identified  in  data  element  (1) 

P21:  Ask  the  user  for  Q3  (employee  identifier  (ID4)  of  the 

person  the  user  would  like  to  schedule  to  perform  the 
task).  Store  this  identifier. 
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P22:  Using  the  DL34  list  and  the  ID10  identified  in  P4, 

determine  whether  the  employee  identified  by  the 
identifier  entered  in  P21  is  qualified  to  perform  the  type 
of  task  (CT8)  identified  in  P12.  Yes  =  P27;  No  =  P40 

P23:  Tell  the  user  that  the  person  entered  is  not  shown  as 

qualified  to  perform  the  type  of  task  specified  by  the 
user  and  that,  therefore,  it  is  not  possible  to  schedule 
this  task  to  be  performed  by  this  person. 

P24:  Ask  the  user  if  the  user  wishes  to  reenter  the  ID4  or 

quit.  Reenter  =  P21 ;  Quit  =  P25 

P25:  Are  there  any  ID23s  on  the  Pi  list?  Yes  =  P26;  No  =  P27 


P26:  60  TO  Pi  of  Step  F4B-2. 
P27 :  GO  TO  P5  of  Step  F4B-1. 


P28: 


Start  a  counter,  called  the  P28  counter,  with  the  value  of 
'O'.  This  will  be  the  counter  of  years. 


P29: 


Start  a  counter,  called  the  P29  counter,  with  the  value  of 
'O'.  This  will  be  the  counter  of  months. 


P30: 


Start  a  counter,  called  the  P30  counter,  with  the  value  of 
‘O'.  This  will  be  the  counter  of  days  of  the  month. 


P31 : 


Start  a  counter,  called  the  P31  counter,  with  the  value  of 
‘O’.  This  will  be  the  counter  of  time  slot  numbers. 


P32:  Ask  the  user  for  Q4  (year  in  which  the  user  would  like  to 

schedule  the  task). 

P33:  Ask  the  user  for  Q5  (month  in  which  the  user  would  like  to 

schedule  the  task). 

P34:  Is  the  year  and  month  entered  in  P32  and  P33  the  same  as 

the  value  stored  in  the  P28  and  P29  counters?  Yes  =  P47; 
No  =  P35 

P35:  Using  the  0141  list,  determine  whether  there  is  a  set  of 

0S27  data  (as  identified  by  a  monthly  schedule  identifier 
(ID27))  for  the  ID4  entered  in  P21,  the  year  entered  in 
P32,  the  month  entered  in  P33  and  the  OHMIS  service  area 
identifier  (1010)  identified  in  P4.  Yes  =  P 45 ;  No  =  P36 

P36:  Using  the  DL40  list  determine  whether  there  are  any  sets 

of  0S26  data  (as  identified  by  a  weekly  schedule 
identifier  (1028))  for  the  104  entered  in  P21  and  the  1010 
from  P4.  Yes  =  P39;  No  =  P37 
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P37:  Tell  the  user  that  it  is  not  possible  to  schedule  a  task 

to  be  performed  by  the  person  specified  because  there  is 
no  existing  weekly  schedule  availability  data  (DS26)  for 
that  person. 

P 38 :  GO  TO  P24. 

P39:  Identify  each  ID28  entered  on  the  DL40  for  the  104  from 

P21  and  the  ID1Q  from  P4.  Examine  the  set  of  DS26  data 
corresponding  to  each  such  ID28.  Is  there  a  set  of  DS26 
data  for  the  ID4  from  P21  and  the  1010  from  P4  that  covers 
the  year  and  month  specified  in  P32  and  P33  (i.e.,  the 
begin  and  end  dates  for  the  DS26  data  include  this  year 
and  month  or  include  a  part  of  it)?  Yes  =  P42 ;  No  =  P40 

P40:  Tell  the  user  that  it  is  not  possible  to  schedule  the  task 

specified  to  be  performed  by  the  person  specified,  because 
there  is  no  0S26  data  for  the  year  and  month  specified  for 
the  person  specified. 

P41:  Ask  the  user  whether  he/she  wishes  to  quite,  specify 

another  employee  to  perform  the  task  or  reenter  the  time 
slot  information.  Quit  =  P25;  Another  employee  =  P21; 
Reenter  =  P33 

P42:  Generate  a  flag  indicating  that  it  was  necessary  to  go  to 

the  Function  F4C  subroutine  from  P42  of  Step  F4B-7  and 
that  the  program  should  return  to  P45  of  Step  F48-7  when 
Function  F4C  is  completed.  Retain  this  flag  throughout 
the  time  that  the  user  is  logged  onto  the  system  or  until 
this  flag  is  erased  at  the  completion  of  Function  F4C. 

P43:  Retain  the  ID10  from  P4,  the  ID4  from  P21,  the  year  from 

P32  and  the  month  from  P33.  This  information  will  be  used 
in  Function  F4C. 

P44:  GO  TO  PI  of  Step  F4C. 

P45:  Identify  the  1027  on  the  DL41  list  for  the  ID4  from  P21, 

the  1010  from  P4,  the  year  from  P 32  and  the  month  from 
P33. 

P46:  Locate  the  DS27  data  corresponding  to  the  ID27  identified 

in  P45. 

P47:  Ask  the  user  for  Q6  (date  of  the  month  in  which  the  user 

wishes  to  schedule  the  task).  (Note:  For  editing 
purposes,  it  should  be  realized  that  this  date,  in 
conjunction  with  the  year  and  month  specified  in  P32  and 
P33,  must  be  after  the  current  date  (R2)  for  the  date  to 
be  an  acceptable  entry.) 
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P48:  Ask  the  user  for  Q7  (time  slot  number  in  which  the  user 

wishes  to  schedule  the  task). 

P49:  Is  the  value  in  the  P28  counter  equal  to  'O'?  Yes  =  P72; 

No  =  P52 

P50:  Skip  this  step. 

P51:  Skip  this  step. 

P52:  Determine  the  distance  in  time  slots  (number  of  15  minute 

periods)  between  the  date  and  time  currently  in  the  P28 
through  P31  counters  and  the  date  and  time  entered  in  P32, 
P33 ,  P47  and  P48.  To  do  this,  follow  these  Processing 
Substeps  (PS): 

PS1:  Start  a  counter,  called  the  PS1  counter,  with  the 

value  ‘O' . 

PS2:  Derive  the  value  that  is  equal  to  the  value  in  P48 

minus  the  value  in  P31.  Add  this  value  to  the  PS1 
counter. 

PS3:  Derive  the  value  that  is  equal  to  the  value  in  P47 

minus  the  value  in  P30,  multiplied  times  '96'.  Add 
this  value  to  the  PS1  counter. 

PS4:  Derive  the  value  equal  to  the  value  in  P33,  minus 

the  value  in  P29.  Is  this  value  equal  to  ’O',  less 
than  'O',  or  greater  than  'O'?  0  =  PS19;  Less  than 

0  =  P5;  Greater  than  0  =  FNA  (PS8) 

PS5:  Derive  the  value  that  is  equal  to  the  value  in  PS4, 

plus  ' 12 * . 

PS6:  Start  a  counter,  called  the  PS6  counter,  with  the 

value  'O' . 

PS 7 :  Start  a  counter,  called  the  PS7  counter,  with  the 
value  in  the  P29  counter. 

FNA:  FOR  'X'  iterations,  where  'X1  is  the  value  derived 

in  PS5  or  in  PS4,  if  PS5  was  never  executed: 

PS8:  Identify  the  value  (month)  in  the  PS7  counter. 

PS9:  Using  Rl,  determine  the  number  of  days  in  the  month 

identified  in  PS8.  Add  this  value  to  the  PS6 
counter. 

Is  the  value  in  the  PS7  counter  equal  to  '12'?  Yes 
=  PS11 ;  No  =  PSI3 


PS10 : 
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PS11:  Change  the  value  in  the  PS7  counter  to  be  '1‘. 

PS12:  GO  TO  PS14  (next  FNA) . 

PS13:  Add  '1'  to  the  value  in  the  PS7  counter. 

PS14:  NEXT  FNA;  end  of  FNA,  GO  TO  PS15. 

PS15:  Was  the  answer  in  PS4  'less  than  O'  or  'greater 

than  O'?  Less  than  0  =  PS16;  Greater  than  0  =  PS18 

PS16:  Multiply  the  value  in  the  PS6  counter  by  '-96'. 

Add  this  product  (negative  number)  to  the  PS  1 
counter. 

PS17 :  GO  TO  PS19. 

PS18;  Multiply  the  value  in  the  PS6  counter  by  '96' .  Add 
this  product  (positive  number)  to  the  PS 1  counter. 

PS19:  Derive  the  value  that  is  equal  to  the  value  in  the 
P32  counter,  minus  the  value  in  the  P28  counter. 

Is  this  value  equal  to  'O',  less  than  'O',  or 
greater  than  'O'?  0  =  P53;  Less  than  0  =  P56; 
Greater  than  0  =  PS20 

PS 20:  Start  a  counter  with  the  value  in  the  P28  counter. 

FNB:  FOR  'X'  iterations,  where  'X'  is  the  value  in 

PS19: 

PS21:  Identify  the  year  in  the  P28  counter. 

PS22:  Using  Rl,  determine  how  many  days  there  are  in  the 
year  for  the  year  identified  in  PS21. 

PS23:  Multiply  the  value  in  PS22,  times  '96'.  Add  this 
product  to  the  PS1  counter. 

PS24:  Add  '1'  to  the  PS20  counter. 

PS25 :  NEXT  FNB;  end  of  FNB,  GO  TO  PS3. 

P53:  Is  the  value  in  the  PS1  counter  equal  to  'O',  less  than 

'O',  or  greater  than  'O'?  0  =  P54;  Less  than  0  =  P56; 

Greater  than  0  =  P58 

P54:  Tell  the  user  that  he/she  has  given  the  same  time  slot  for 

scheduling  more  than  once  and  this  is  not  acceptable. 


Pb5:  GO  TO  P41. 
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P56:  Tell  the  user  that  he/she  must  apply  the  time  slots  in 

which  he/she  wishes  to  schedule  the  task  in  chronological 
order  and,  because  this  has  not  been  done,  this  is  not  an 
acceptable  time  slot. 

P57:  GO  TO  P41. 

P58:  Is  the  value  in  the  PS1  counter  greater  than  1 1'?  Yes  = 

P59;  No  =  P72 

P59:  Derive  the  value  that  is  equal  to  the  value  in  the  PI7 

counter,  plus  ' 1 ‘ . 

P60:  Tell  the  user  that  there  will  be  'X'  interruptions  in  the 

scheduling  of  the  task,  if  the  scheduling  is  done  in 
accordance  with  the  user  specifications,  where  'X'  is  the 
value  derived  in  P59.  Ask  the  user  if  this  is  acceptable. 
Yes  =  P61;  No  =  P41 

P61 :  Is  the  value  in  the  P16  counter  less  than  '3'?  Yes  =  P62; 

No  =  P63 

P62:  Tell  the  user  that,  if  the  task  is  scheduled  in  accordance 

with  his/her  specifications,  the  task  will  have  an 
interruption  after  less  than  three-quarters  of  an  hour's 
work  on  the  task  since  the  start  of  the  task  or  since  the 
last  interruption.  Ask  the  user  if  this  is  acceptable. 

Yes  =  P63;  No  =  P41 

P63:  Derive  the  value  that  is  equal  to  the  value  in  the  P15 

counter,  minus  the  value  in  the  P17  counter. 

P64:  Derive  the  value  that  is  equal  to  the  value  from  P5,  minus 

the  value  derived  in  P63.  Is  this  value  greater  than  ’3’? 
Yes  =  P65;  No  =  P66 

P65:  Tell  the  user  that,  if  the  task  is  scheduled  in  accordance 

with  his/her  specifications,  the  task  will  have  an 
interruptions  with  less  than  three-quarters  of  an  hour's 
time  left  to  complete  the  task.  Ask  the  user  whether  this 
is  acceptable.  Yes  =  P66;  No  =  P41 

P66:  Oerive  the  value  that  is  equal  to  the  value  in  the  P18 

counter  plus  the  value  in  the  PS1  counter. 

P67:  Is  the  answer  given  in  P8  ('employee  transport'  task?)  a 

'Yes'  or  a  'No'?  Yes  =  P68;  No  =  P 72 

P68:  Is  the  value  in  the  PSi  counter  greater  than  '3'?  Yes  = 

P69;  No  =  P70 
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P69:  Tell  the  user  that,  if  the  task  is  scheduled  in  accordance 

with  the  user  specifications,  there  will  be  more  than  a 
three-quarters  of  an  hour  interruption  in  the  scheduling 
of  an  'employee  transport'  task.  Ask  the  user  if  this  is 
acceptable.  Yes  =  P70;  No  =  P41 

P7Q:  Is  the  value  derived  in  P66  equal  to  or  greater  than  the 

value  from  P5?  Yes  =  P71;  No  =  P72 

P71:  Tell  the  user  that,  if  the  task  is  scheduled  as  the  user 

has  specified,  the  total  length  of  calendar  time  to 
conduct  the  task  will  be  equal  to  or  greater  than  the 
total  time  to  conduct  the  task  and  the  task  is  an 
'employee  transport'  task.  Ask  the  user  if  this  is 
acceptable.  Yes  =  P72;  No  =  P41 

P72:  Locate  the  time  slot  on  the  DS27  data  located  in  P46  that 

is  for  the  date  entered  in  P47  and  the  time  slot  number 
entered  in  P48. 

P?3:  Ooes  the  DS27  data  from  P46  indicate  that  the  time  slot 

identified  in  P49  is  available  for  scheduling?  Yes  *  P76; 
No  =  P74 

P74:  Tell  the  user  that  the  time  slot  specified  by  the  user  is 

not  available  for  scheduling  tasks  for  the  person  that  the 
user  specified  to  perform  the  task  and,  therefore,  this 
task  cannot  be  scheduled  in  this  time  slot. 

P75 :  GO  TO  P41. 

P76:  Was  the  answer  to  P6  (dated  task?)  a  'Yes'  or  a  ’No'?  Yes 

=  P77 ;  No  =  P79 

P77:  Is  the  due  date  identified  in  P7  equal  to  or  before  the 

date  entered  in  P32  (year),  P33  (month)  and  P47  (day  of 
the  month)?  Yes  =  P 78 ;  No  =  P79 

P78:  Tell  the  user  that,  if  the  task  is  scheduled  as  specified, 

it  will  not  be  completed  before  the  due  date  for  the  task. 
Ask  the  user  if  this  is  acceptable.  Yes  =  P 79 ;  No  =  P41 

P79:  Was  the  answer  to  P10  (restrictions?)  a  'Yes'  or  a  'No'? 

Yes  *  P80;  No  =  P88 

P80:  Does  PiO  indicate  that  there  are  special  restriction  dates 

for  the  task  being  scheduled?  Yes  -  P8I;  No  =  P84 

P81 :  Is  the  date  entered  in  P47  one  of  the  special  restriction 

dates  (or  between  one  of  the  ranges  of  special  restriction 
dates)  stored  in  PiO?  Yes  =  P82;  No  =  P83 
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P82:  Tell  the  user  that  the  scheduling  of  the  task  as  specified 

would  result  in  scheduling  the  task  on  a  date  restricted 
for  scheduling  the  task  specified.  Ask  the  user  whether 
this  scheduling  of  the  task  is  still  acceptable.  Yes  = 
P83;  No  =  P41 

P83:  Doe  P10  indicate  that  there  are  standard  restrictions  for 

the  task  being  scheduled.  Yes  =  P84;  No  =  P88 

P84:  Using  Rl,  determine  the  day  of  the  week  for  the  date 

identified  in  P32  (year),  P33  (month)  and  P47  (date  of  the 
month) . 

P85:  Locate  the  DS26  data  corresponding  to  the  ID28  stored  in 

P10. 

P86:  Locate  the  time  slot  on  the  DS26  data  located  in  P85  that 

is  for  the  day  of  the  week  identified  in  P84  and  the  time 
slot  number  entered  in  P48.  Is  this  time  slot  restricted? 
Yes  =  P87 ;  No  =  P88 

P87:  Tell  the  user  that  the  scheduling  of  the  task  as  specified 

would  result  in  scheduling  the  task  on  a  date  that  is 
restricted  for  scheduling  the  task.  Ask  the  user  if  this 
is  acceptable.  Yes  =  P88;  No  =  P41 

P88:  Identify  the  preferred  time  use  code  (CT11)  for  the  time 

slot  identified  in  P49  on  the  DS27  data  located  in  P46. 

Is  this  CT11  the  same  as  the  CTil  identified  in  P9?  Yes  = 
P90;  No  =  P89 

P89:  Tell  the  user  that,  if  the  task  is  scheduled  as  specified, 

it  will  mean  that  at  least  one  of  the  time  slots  will  be 
scheduled  for  a  time  for  which  the  preferred  time  use  of 
the  specified  performer  of  the  task  for  that  time  use  is 
not  to  do  tasks  of  the  type  being  scheduled.  Ask  the  user 
if  this  is  acceptable.  Yes  =  P90;  No  =  P41 

P90:  Determine  whether  the  time  slot  identified  in  P49  on  the 

DS27  data  located  in  P47  is  shown  as  currently  scheduled. 
Yes  =  P91;  No  =  P95 

P91:  Identify  the  task  identifier  (ID23)  of  the  task  shown  as 

currently  scheduled  in  the  time  slot  identified  in  P49. 

P92:  Is  the  ID23  identified  in  P91  the  same  as  the  1D23  entered 

■>n  P2?  Yes  =  P95;  No  =  P93 

Using  the  DS27  data  located  in  P46  on  the  time  slot 
located  in  P49,  identify  the  characteristics  of  the  task 
currently  scheduled  in  the  P49  time  slot.  These 
characteristics  are:  Whether  the  task  is  one  that  is 


P93 : 
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scheduled  by  the  user;  whether  there  are  any  restrictions 
on  the  task,  and  if  so,  what  type  (standard,  special  or 
both);  whether  the  task  is  a  dated  task,  i.e.,  has  a  due 
date;  whether  the  task  was  initiated  by  a  Reminder  Notice 
type  of  suspense  data  or  a  requirement  type  of 
appl icabi 1 ity  data,  and,  if  a  requirement  type 
applicability  data,  whether  it  was  initiated  by  a 
mandatory  or  recommended  requirement;  whether  the  task  was 
an  'employee  transport1  task;  and,  whether  the  task 
requires  sending  out  a  Scheduling  Notice  (015)  (i.e., 
whether  the  task  is  such  that  the  participants  in  the  task 
would  have  already  been  notified  about  the  task). 

P94:  Tell  the  use>'  that,  if  the  task  being  scheduled  is 

scheduled  in  accordance  with  the  user  specifications,  it 
will  mean  rescheduling  a  task  that  is  already  scheduled  in 
the  time  slot  most  recently  specified  by  the  user  for 
scheduling.  Present  the  characteristics  of  the  task  that 
will  need  to  be  rescheduled  to  tne  user  (as  identified  in 
P93).  Ask  the  user  wnether  his/her  specifications  for 
scheduling  of  the  task  are  still  acceptable,  even  though 
another  task  will  need  to  be  rescheduled.  Yes  =  P95;  No  = 
P41 

P95:  Add  'l*  to  the  P15  counter. 

P96:  Was  the  value  in  the  PS1  counter  greater  than  '1‘?  Yes  = 

P97;  No  =  P100 

P 9 7 :  Add  '1'  to  the  P 1 7  counter. 

P98:  Add  the  value  in  the  PS1  counter  to  the  P18  counter. 

P99:  Set  the  P 16  counter  to  be  'O'. 

PiOO:  Add  the  value  in  the  PSl  counter  to  the  P16  counter. 

P101:  Erase  the  value  in  the  P28  through  P31  counters. 

P102:  Place  the  value  entered  in  P32,  P33,  P 4 7  and  P48  onto  the 
P28  through  P 31  counters,  respecti vely. 

P103:  Make  an  entry  to  the  P20  list.  Data  element  (1)  should  be 
the  1D27  from  P45  (part  (1)),  the  date  entered  in  P47 
(part  (2))  and  the  time  slot  number  entered  in  P48  (part 
(3)).  Da. a  element  (2)  should  be  the  current  value  in  the 
P15  counter.  Data  element  (3)  should  be  the  current  value 
in  the  P17  counter. 

P104;  Derive  the  value  equal  to  the  value  in  the  P15  counter 
minus  the  value  in  the  P 1 7  counter.  Is  this  value  equal 
to  the  value  from  PS?  Yes  (.i.e.,  the  user  has  finished 
scheduling  the  task)  -  P105;  No  =  P32 
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P 105 :  Was  the  answer  in  P 1 3  (whether  the  task  being  scheduled 
had  already  been  scheduled)  a  'Yes'  or  a  'No'?  Yes  = 

P 106 ;  No  =  P124 

P106:  Using  the  0S24  data  from  P3,  identify  the  time  slot 

information  for  the  start  time  of  the  task  identified  in 
P2. 

P107:  Locate  the  0S27  data  corresponding  to  the  monthly  schedule 
identifier  (ID27)  that  is  part  (1)  of  the  time  slot 
information  located  in  P106. 

P 10 8 :  Erase  all  scheduling  information  from  the  DS24  data 

located  in  P3,  i.e.,  the  information  about  the  scheduling 
of  the  task  as  it  was  previously  scheduled  (e.g.,  start 
and  end  time  slot  information,  whether  the  task  was 
scheduled  before  the  due  date,  number  of  interruptions, 
etc.).  Do  not  erase  the  information  about  whether  more 
than  one  person  will  perform  this  task. 

FN1:  FOR  each  time  slot  in  which  the  task  from  P2  was 

previously  scheduled,  beginning  with  the  time  slot 
identified  in  P106  and  the  DS27  data  from  P 10 7  and 
continuing  with  the  time  slot  identified  in  Pill: 

P 10 9 :  Locate  the  time  slot  for  this  iteration  of  FNl.  (Follow 
the  instructions  given  in  P15  of  Step  F4B-1.) 

PI 10 :  Determine  whether  the  scheduling  of  the  task  is  to 

continue  to  another  time  slot.  (This  information  is  shown 
on  the  DS27  data  for  the  time  slot  located  in  P109.)  Yes 
=  Pill;  No  =  P 114 

Pill:  Identify  the  next  time  slot  in  which  the  scheduling  of  the 
task  is  to  continue  to.  (From  the  DS27  data  for  the  P109 
time  slot. ) 

P112:  Erase  all  of  the  scheduling  information  for  the  task 

identified  in  P2  from  the  time  slot  for  this  iteration  of 
FNl  (as  identified  in  P109),  i.e.,  from  the  DS27  data. 

P 1 1 3 :  NEXT  FNl.  (End  of  FNl  will  not  be  reached.) 

P 1 1 4 :  Using  the  DS24  data  located  in  P3  determine  whether  the 

task  identified  in  P2  has  more  than  one  person  scheduled 
to  perform  the  task.  Yes  =  P 1 1 5 ;  No  =  P 12 4 

P 1 1 5 :  Identify  the  up  to  3  monthly  schedule  identifiers  (1027) 
on  tne  US24  data  located  in  P3  that  specify  the  monthly 
schedule  data  (DS27;  on  which  the  scheduling  for  the  task 
for  the  additional  persons  scheduled  to  perform  the  task 
is  shown  to  start.  Put  the  starting  ID27s  on  a 
temporary  list,  called  the  P 1 1 5  list. 
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FN2:  FOR  each  1027  on  the  P115  list: 

P 116 :  Locate  the  DS27  data  corresponding  to  the  ID27  for  this 
iteration  of  FN2. 

FN2.1:  FOR  each  time  slot  in  which  the  task  identified  in  P2  is 
already  scheduled  and  is,  therefore,  also  to  be  scheduled 
for  an  additional  person  to  perform  the  task  at  the  same 
time,  beginning  with  the  date  of  the  month  and  the  time 
slot  number  that  are  parts  (2)  ard  (3)  of  the  start  time 
slot  identified  in  P106  on  the  DS27  data  located  in  P 1 1 6 
and  continuing  with  the  time  slot  identified  in  P 1 1 9 : 

Pi 1 7 :  Locate  the  time  slot  for  this  iteration  of  FN2.1.  (Follow 
the  instructions  given  in  P15  of  Step  F4B-1.) 

PI 1 8 :  Determine  whether  the  scheduling  of  the  task  continues  to 
another  time  slot.  (This  information  is  shown  on  the  DS27 
data  for  the  time  slot  for  this  iteration  of  FN2.1  as 
located  in  P 117 . )  Yes  =  P 1 1 9 ;  No  =  P 122  (next  FN2) 

PU9:  Identify  the  next  time  slot  in  which  the  scheduling  of 

this  task  will  continue.  (From  the  DS27  data  for  the  P 1 1 7 
time  slot. ) 

P12U:  Erase  all  of  the  scheduling  information  for  the  task 

identified  in  P2  from  the  0S27  data  time  slot  located  in 
P 11 7 . 

P121:  NEXT  FN2.1.  (End  of  FN2.1  will  not  be  reached.) 

P122 :  NEXT  FN2;  end  of  FN2,  GO  TO  P123. 

P123:  Change  the  answer  to  the  question  on  the  DS24  data  located 
in  P3  about  whether  there  are  additional  persons  scheduled 
to  perform  this  task  to  be  'No'.  Erase  the  information 
about  the  additional  persons  previously  scheduled  to 
perform  this  task  shown  on  the  DS24  data. 

P 124 :  Begin  entering  the  new  scheduling  information  for  the  task 
identified  in  P2  onto  the  OHM  I S  data  base.  First, 
complete  the  0S24  data  located  in  P3.  Answer  the  question 
about  whether  the  user  specified  the  schedule  as  'Yes'. 
Answer  the  question  about  whether  the  task  is  scheduled  as 
'Yes'  and  remove  the  code  (A-D),  if  any,  explaining  why 
the  task  could  not  be  scheduled.  Enter  the  value  in  data 
element  (1)  of  the  first  entry  on  the  P20  list  as  the  time 
slot  information  for  when  the  task  is  scheduled  to  start. 
Enter  the  value  in  data  element  (1)  on  the  last  entry  on 
the  P20  list  as  the  time  slot  for  when  the  task  is 
scheduled  to  be  completed.  Enter  the  value  in  data 
element  (3)  on  the  last  entry  on  the  P2G  list  as  the  value 
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for  the  total  number  of  interruptions  in  the  scheduling  of 
the  task.  Enter  the  value  currently  in  the  P15  counter  as 
the  actual  number  of  time  slots  scheduled. 

P 12 5 :  Is  the  1023  entered  in  P2  and  the  1010  from  P4  on  the  DL31 

list?  Yes  =  P126;  No  =  P127 

P126:  Remove  the  1023  entered  in  P2  and  the  1010  from  P4  from 
the  0131  list.  GO  TO  P132. 

P127:  Is  the  task  identifier  (ID23)  entered  in  P2  and  the  OHMIS 
service  area  identifier  (1010)  from  P4  on  the  DL39  list? 
Yes  =  P128;  No  =  P129 

P 128 :  Remove  the  1023  entered  in  P_  and  the  I  DIO  from  P4  from 
the  DL39  1  ist.  GO  TO  P132. 

P129:  Skip  this  step. 

P 1 30 :  Skip  this  step. 

P131:  Skip  this  step. 

P132:  Does  the  task  identified  in  P2  require  a  Scheduling  Notice 
(015)  (as  determined  in  P 1 1 ) ?  Yes  =  P 133 ;  No  =  FN3  (P134) 

P 133 :  Use  the  DS24  data  located  in  P3  to  generate  a  Scheduling 
Notice  (015)  for  the  task  identified  in  P2. 

FN3:  FOR  each  entry  on  the  P20  list: 

P134:  Identify  the  ID27  contained  in  part  (1)  of  data  element 
(1)  for  the  P20  list  entry  in  this  iteration  of  FN3. 

P135:  Locate  the  0S27  data  corresponding  to  the  1027  from  P134. 

P 1 36 :  On  the  DS27  data  from  P135  locate  the  time  slot  equivalent 
to  the  day  of  the  month  (1-31)  and  the  time  slot  number 
(1-96)  that  are  parts  (1)  and  (2)  of  data  element  (1)  of 
the  P20  list  entry  for  this  iteration  of  FN3. 

P137:  Examine  the  preferred  time  use  code  (CT11)  for  the  time 
slot  located  in  P136.  Is  this  CT11  the  same  as  the  CT11 
from  P 9?  Yes  =  P139;  No  =  P138 

P138:  Generate  a  flag,  called  the  P 138  flag,  indicating  that  at 
least  one  of  the  time  slots  in  which  the  task  identified 
in  P2  is  schedule  is  not  in  the  correct  preferred  time 
use.  If  this  flag  has  already  been  generated,  skip  this 
step. 
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P139:  Is  the  time  slot  located  in  P136  currently  shown  as 
scheduled?  Yes  =  P140;  No  =  P144 

P140:  Identify  the  task  identifier  (ID23)  of  the  task  that 

currently  is  scheduled  in  the  time  slot  located  in  P136. 

P 141 :  Is  the  1023  identified  in  P140  currently  on  the  PI  list? 
Yes  =  P 143 ;  No  =  P142 

P142:  Add  the  1023  identified  in  P140  to  the  PI  list. 

P143:  Erase  all  of  the  scheduling  information  for  the  task 

identified  in  P140  from  the  DS27  data  time  slot  located  in 
P136. 

P144:  Fill  in  the  empty  fields  of  the  time  slot  located  in  P136 
with  the  scheduling  information  about  the  task  identified 
in  P2.  To  do  this,  follow  these  instructions:  The  task 
identifier  should  be  the  ID23  from  P2.  The  time  use  code 
(CT11)  for  the  task  should  be  the  time  use  code  from  P9. 
The  answer  as  to  whether  the  scheduling  was  specified  by 
the  user  should  be  'Yes'.  The  answer  as  to  whether  there 
are  any  restrictions  on  the  scheduling  of  this  task  and, 
if  so,  what  type  of  restrictions  they  are,  should  be  the 
information  from  P10.  The  user  specified  number  of  time 
slots  for  the  task  is  from  Y5~.  The  actual  number  of 
time  slots  scheduled  is  from  the  P 15  counter.  The  due 
date,  if  any,  is  from  P7.  Whether  the  task  is  an 
'employee  transport'  task  is  from  P8.  The  cumulative 
number  of  time  slots  scheduled  for  the  task  and  the 
cumulative  number  of  interruptions  in  the  scheduling  of 
the  task  as  of  this  time  slot  are  from  data  elements  (2) 
and  (3)  of  the  P20  list  entry  for  this  iteration  of  FN3. 
Whether  the  scheduling  for  this  task  is  continued  is 
answered  'Yes',  unless  this  iteration  of  FN3  is  the  last 
P20  list  entry,  in  which  case  the  answer  is  'No'  (and  no 
continuing  time  slot  information  is  supplied).  The  time 
slot  information  for  the  next  time  slot  in  which  the  task 
scheduled  continues  is  in  data  element  (1)  of  the  P20  list 
entry  that  follows  the  P20  list  entry  for  this  iteration 
of  FN3.  The  rest  of  the  entries  onto  the  DS27  data  time 
slot  located  in  P137  come  from  PI 1 . 

P145 :  NEXT  FN3;  end  of  FN3,  GO  TO  P146. 

P146:  Is  there  a  P138  flag?  Yes  =  P147;  No  =  P148 

P147:  Answer  the  question  on  the  DS24  data  from  P3  about  whether 
the  task  is  scheduled  in  the  correct  time  use  code  (CT11) 
with  the  answer  ' No' . 
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P148:  Was  the  answer  to  P6  (dated  task?)  a  ‘Yes'  or  a  'No'?  Yes 
=  P149;  No  =  P155 

P 149 :  Identify  the  1027  that  is  part  (1)  of  data  element  (1)  in 
the  last  entry  on  the  P20  list. 

PI50:  Locate  the  DS27  data  corresponding  to  the  ID27  from  P149. 

P151:  Identify  the  year  and  month  covered  by  the  DS27  data 
located  in  P150. 

P152:  Identify  the  date  of  the  month  that  is  part  (1)  of  data 
element  (1)  on  the  last  entry  on  the  P20  list. 

P153:  Is  the  date  that  is  made  up  of  the  year  and  month 

identified  in  P151  and  the  date  of  the  month  from  P152 
equal  to  or  later  than  the  due  date  for  the  task  given  in 
P7?  Yes  =  P154;  No  =  P155 

P 154 :  Answer  the  question  on  the  DS24  data  from  P3  about  whether 
the  task  was  scheduled  before  the  due  date  with  the  answer 
'No'.  GO  TO  P25. 

P155:  Answer  the  question  on  the  DS24  data  from  P3  about  whether 
the  task  was  scheduled  before  the  due  date  with  the  answer 
'Yes'.  GO  TO  P25. 

P156:  (From  P14):  Determine  from  the  DS24  data  from  P3  whether 
the  number  of  additional  persons  currently  scheduled  to 
perform  this  task  is  '3'.  Yes  =  P157;  No  =  P159 

P157:  Tell  the  user  there  are  currently  3  additional  persons 
already  scheduled  to  perform  this  task  and  that  no  more 
can  be  added. 

P158:  GO  TO  P25. 

P159:  Ask  the  user  for  Q8  (employee  identifier  (ID4)  of  the 

additional  person  the  user  would  like  to  have  perform  this 
already  scheduled  task). 

P160:  Is  the  ID4  from  P159  currently  on  the  DS24  data  from  P3  as 
one  of  the  additional  persons  scheduled  to  perform  this 
task?  Yes  =  P16l;  No  =  P163 

P161:  Tell  the  user  that  the  person  specified  is  already 
scheduled  to  perform  the  task  specified. 

P162:  Ask  the  user  whether  the  user  wishes  to  quit  or  to  reenter 
the  employee  identifier.  Quit  =  P25;  Reenter  =  P 159 
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P163:  Identify  the  start  time  slot  information  for  the  task 
identified  in  P2  as  shown  on  the  DS24  data  from  P3. 

P164:  Locate  the  DS27  data  corresponding  to  the  monthly  schedule 
identifier  (1027)  that  is  part  (1)  of  the  start  time  slot 
identified  in  P163. 

P165:  Identify  on  the  DS27  data  from  P164  the  employee 

identifier  (104)  that  is  the  person  for  whom  the  DS27  data 
located  in  P164  is  a  monthly  schedule. 

PI66:  Is  the  104  identified  in  P165  the  same  as  the  ID4  entered 
in  P 159 ?  Yes  =  P 161 ;  No  =  P167 

P167:  Using  the  0L34  list  and  the  ID10  from  P4,  determine 

whether  the  ID4  entered  in  P159  is  qualified  to  perform 
the  type  of  task  (CT8)  identified  in  P12.  Yes  =  P170;  No 
=  P163 

PI68:  Tell  the  user  that  the  person  specified  is  not  qualified 
to  perform  the  task  and,  therefore,  cannot  be  scheduled  to 
perform  the  task. 

P169:  GO  TO  P162. 

P170:  Generate  a  list,  called  the  PI 70  list.  This  list  looks 
similar  to  the  P20  list.  The  first  3  data  elements  are 
the  same  as  the  P20  list  format.  Data  element  (4)  is 
another  set  of  3  part  time  slot  information  (i.e.,  an 
ID27,  a  date  of  the  month,  and  a  time  slot  number). 

P17I:  Start  a  marker,  called  the  P171  marker,  with  the  monthly 
schedule  identifier  (ID27)  that  is  part  (1)  of  the  start 
time  slot  identified  in  P163. 

P172:  Start  a  marker,  called  the  P172  marker,  with  the  date  of 
the  month  that  is  part  (2)  of  the  P163  time  slot. 

P 1 73 :  Start  a  marker,  called  the  P173  marker,  with  the  time  slot 
number  that  is  part  (3)  of  the  P163  time  slot. 

P174:  Locate  the  DS27  data  corresponding  to  the  ID27  currently 
in  P171 . 

Pi 75 :  Identify  the  year  and  month  covered  by  the  DS27  data 
located  in  P174. 

P176:  Using  the  DL4I  list,  determine  if  there  is  a  set  of  DS27 
data  (as  identified  by  a  monthly  schedule  identifier 
(ID27))  for  the  ID4  entered  in  P159,  the  year  and  month 
identified  in  PI75  and  the  I  DIO  from  P4.  Yes  =  P186;  No  = 
P  i  7/ 
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P177:  Using  the  DL40  list,  determine  whether  there  are  any  sets 
of  DS26  data  (as  identified  by  the  weekly  schedule 
identifier  (1028))  for  the  ID4  entered  in  P159  and  the 
1010  from  P4.  Yes  =  P180;  No  =  P178 

P178:  Tell  the  user  that  it  is  not  possible  to  schedule  the  task 
specified  by  the  user  to  be  performed  by  the  additional 
person  specified  by  the  user,  because  the  current 
scheduling  of  the  task  is  such  that  this  additional  person 
does  not  have  time  available  for  scheduling  for  at  least 
one  of  the  time  slots  in  which  the  task  is  currently 
scheduled. 

P179:  GO  TO  P162. 

P180:  Identify  each  entry  (ID28)  on  the  DL40  for  the  104  from 
Plb9  and  the  1010  from  P4.  Examine  the  set  of  DS26  data 
corresponding  to  each  such  ID28.  Is  there  a  set  of  DS26 
data  for  the  ID4  from  P159  and  the  ID10  from  P4  that 
covers  the  year  and  month  specified  in  P 1 75  (i.e.,  the 
begin  and  end  dates  for  the  DS26  data  includes  some  part 
of  this  year  and  month)?  Yes  =  P183;  No  =  P181 

P181:  Tell  the  user  that  it  is  not  possible  to  schedule  the  task 
specified  to  be  performed  by  the  person  specified,  because 
there  is  no  DS26  data  for  the  year  and  month  specified  for 
the  person  specified. 

P182 :  GO  TO  P162. 

P183:  Generate  a  flag  indicating  that  it  was  necessary  to  go  to 
the  Function  F4C  subroutine  from  P183  of  Step  F4B-7  and 
that  the  program  should  return  to  P186  of  Step  F4B-7  when 
the  Function  F4C  subroutine  is  completed.  Retain  this 
flag  throughout  the  time  that  the  user  is  logged  onto  the 
system  or  until  this  flag  is  erased  at  the  completion  of 
Function  F4C. 

P184:  Retain  the  1010  from  P4,  the  ID4  from  P 1 59 ,  and  the  year 
and  month  from  P175.  This  information  will  be  used  in 
Function  F4C. 

P 18b :  GO  TO  PI  of  Step  F4C. 

P186:  Locate  the  0S27  data  corresponding  to  the  ID27  currently 
stored  in  the  PI 71  marker. 

P187:  Locate  the  time  slot  on  the  DS27  data  located  in  P186  that 
is  for  the  date  of  the  month  and  the  time  slot  number 
currently  stored  in  P172  and  P173. 


P188:  Identify  the  number  of  cumulative  time  slots  scheduled  and 
cumulative  number  of  interruptions  in  scheduling  given  in 
the  time  slot  identified  in  P187. 

?189:  Generate  a  P170  list  entry.  Place  the  value  in  the  P171 
through  P173  markers  are  parts  (I)  through  (3)  of  data 
element  (1)  on  the  new  P170  list  entry.  Place  the 
cumulative  number  of  time  slots  scheduled  and  cumulative 
number  of  interruptions  in  scheduling  identified  in  P198 
as  data  elements  (2)  and  (3). 

P190:  Does  the  DS27  data  time  slot  located  in  P187  indicate  that 
the  scheduling  of  the  task  identified  in  P2  continues  onto 
another  time  slot?  Yes  =  P191;  No  =  FN4  (P197) 

P191:  Identify  the  next  time  slot  on  which  the  task  identified 
in  P2  continues.  This  is  shown  on  the  DS27  data  time  slot 
located  in  P187. 

P192:  Is  the  1027  that  is  part  (1)  of  the  time  slot  identified 
in  P191  the  same  as  the  1027  currently  in  the  Pi 71  marker? 
Yes  =  P193;  No  =  P195 

PI93:  Place  parts  (1),  (2),  and  (3)  of  the  time  slot  identified 
in  PI91  onto  the  P17I  through  PI 73  markers,  respectively. 
(Oo  not  add  them  to  the  values  in  the  markers,  simply 
replace  the  existing  values  with  these  values.) 

Pi 94:  GO  TO  P186. 

P195:  Places  parts  (1),  (2),  and  (3)  of  the  time  slot  identified 
in  P19I  onto  the  P 1 71  through  P173  markers.  (Do  not  add 
them,  just  replace  the  existing  markers  with  these 
values. ) 

P196:  GO  TO  P174. 

FN4:  FOR  each  entry  on  the  P170  list: 

P197:  Locate  the  DS27  data  corresponding  to  the  1027  in  part  (1) 
of  data  element  (1)  on  the  P 1 70  list  entry  for  this 
iteration  of  FN4. 

P 198 :  Identify  the  year  and  month  covered  by  the  DS27  data 
located  in  P197. 

P199:  Using  the  0141  list,  identify  the  1027  corresponding  to 

the  104  from  P159,  the  I D10  from  P4  and  the  month  and  year 
identified  in  P198. 

P200:  Locate  the  0527  data  corresponding  to  the  1027  from  P199. 
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P201:  Locate  the  time  slot  on  the  DS27  data  from  P200  with  the 
day  of  the  month  and  time  slot  number  equal  to  parts  (2) 
and  (3)  of  data  element  (1)  on  the  P170  list  entry  for 
this  iteration  of  FN4. 

P202:  Does  the  DS27  data  time  slot  located  in  P201  show  that 

this  time  slot  is  available  for  scheduling,  i.e.,  could  be 
scheduled  regardless  of  whether  it  is  or  is  not  scheduled? 
Yes  =  P203;  No  =  P205 

P203:  Generate  data  element  (4)  of  the  P170  list  entry  for  this 
iteration  of  FN4.  Part  (1)  is  the  ID27  identified  in 
P199.  Parts  (2)  and  (3)  are  the  same  as  parts  (2)  and  (3) 
of  data  element  (1)  of  the  Pi 70  list  entry  for  this 
iteration  of  FN4. 

P204 :  NEXT  FN4;  end  of  FN4,  GO  TO  FN5  (P207). 

P205:  Tell  the  user  that  it  is  not  possible  to  schedule  the  task 

specified  to  be  performed  by  the  additional  person 
specified,  because  at  least  one  of  the  time  slots 
scheduled  for  the  task  is  not  available  for  scheduling  for 
that  person. 

P206:  GO  TO  P162. 

FN5:  FOR  each  entry  on  the  P170  list: 

P207:  Locate  the  DS27  data  corresponding  to  the  ID27  that  is 

part  (1)  of  data  element  (4)  (not  data  element  (1))  on  the 
P170  list  entry  for  this  iteration  of  FN5. 

P208:  Locate  the  time  slot  on  the  DS27  data  located  in  P207  that 

is  for  the  day  of  the  month  and  the  time  slot  number  that 

are  in  parts  (2)  and  (3)  of  data  element  (4)  on  the  P170 
list  entry  for  this  iteration  of  FN5. 

P209:  Is  the  time  slot  located  in  P208  currently  shown  as 
scheduled?  Yes  =  P210;  No  =  P214 

P210:  Identify  the  task  identifier  (ID23)  for  the  task  that  is 
currently  scheduled  in  the  time  slot  located  in  P208. 

P211:  Is  the  ID23  from  P210  already  on  the  Pi  list?  Yes  =  P213; 
No  =  P212 

P212:  Add  the  ID23  identified  in  P21U  to  the  PI  list. 

P213:  Erase  all  of  the  scheduling  information  for  the  task 

identified  in  P210  from  the  DS27  data  time  slot  located  in 
P208. 
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P214:  Fill  in  the  empty  fields  on  the  time  slot  located  in  P208 
with  the  scheduling  information  about  the  task  identified 
in  P2.  This  is  done  in  the  same  way  as  described  in  P144, 
except  that  the  cumulative  number  of  time  slots  scheduled 
and  the  cumulative  number  of  interruptions  in  this 
scheduling  should  be  obtained  from  the  values  in  data 
elements  (2)  and  (3)  on  the  P 1 70  list  entry  for  this 
iteration  of  FN6. 

P215 :  NEXT  FN5 ;  end  of  FN5,  GO  TO  P216. 

P216:  Using  the  DS9  data,  identify  the  OHMIS  user/position 

identifier  (1013/1014)  for  the  employee  identifier  (ID4) 
given  in  P 159 - 

P217:  Is  the  answer  on  the  DS24  data  from  P3  for  whether  there 
are  any  additional  persons  scheduled  to  perform  this 
task  a  'Yes'  or  a  'No'?  Yes  =  P219;  No  =  P218 

P218:  Change  the  answer  on  the  DS24  data  from  P3  about  whether 
there  are  any  additional  persons  scheduled  to  perform 
the  task  to  be  a  ' Yes' . 

P219:  Ente1"  the  information  onto  the  DS24  data  from  P3  about  the 
additional  persons  scheduled  to  perform  the  task. 
Specifically,  enter  the  104  from  P159,  the  ID13/ID14  from 
P2I6,  the  1027  that  is  part  (1)  on  data  element  (4)  of  the 
first  entry  on  the  P170  list,  and  the  1027  that  is  part 
(1)  on  data  element  (4)  on  the  last  entry  on  the  P170 
list. 

P220:  GO  TO  P25. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 


015: 


Scheduling  Notice 


FUNCTION  F4C 


Function  for  Routine  Generation  of  Tentative 
Monthly  Schedule  Availability  Data 

(Functional  Data  Flow) 


In  this  Function,  the  program  generates  a  "blank"  set  of  monthly 
schedule  data  (DS27)  for  a  particular  user  (i.e.,  a  particular 
performer  of  OHMIS  tasks).  This  "blank"  DS27  data  shows:  (1)  the 
time  slots  that  the  user  has  available  for  scheduling,  and  (2)  the 
preferred  time  use  (CTI1)  for  each  time  slot,  i.e.,  the  type  of  tasks 
for  which  the  user  would  like  to  be  scheduled  for  each  time  slot.  The 
DS27  data  shows  these  two  pieces  of  information  for  a  particular 
month  of  a  particular  year.  The  DS27  data  is  generated  from  the 
regular  weekly  scheduled  data  (DS26).  The  DS26  data  shows  the  same 
two  pieces  of  information  for  any  week  in  any  time  period  between 
the  begin  and  end  dates  specified  on  the  DS26  data. 

The  purpose  behind  having  these  two  sets  of  availability  in  preferred 
time  use  information  is  that  it  means  that  the  user  need  specify  his/ 
her  regular  availability  and  preferred  time  use  only  once  (on  the 
DS26  data).  The  OHMIS  program  will  continue  to  use  this  regular 
availability/preferred  time  use  for  an^  time  period  for  as  long  as 
the  data  is  applicable  (i.e.,  for  the  time  between  the  begin  and  end 
dates  shown  on  the  0S26  data)  to  determine  the  user's  availability/ 
preferred  time  use  (for  a  particular  time  period)  without  further 
action  required  by  the  user. 

It  is  in  the  Function  F4C  that  the  OHMIS  program  takes  this  regular 
availability/preferred  time  use  data  from  the  DS26  data  set  for  an 
individual  and  uses  it  to  generate  a  set  of  DS27  data  showing 
avai 1 abi 1 i ty/preferred  time  use  data  for  a  particular  month  of  a 
particular  year  for  that  individual.  This  "blank"  DS27  data  is  then 
"filled  in"  (in  Function  F4A  and  Step  F4B-7)  with  the  scheduling  of 
tasks.  In  doing  this,  the  program  conforms  with  the  availability  of 
preferred  time  use  shown  on  the  OS27  data. 

If  in  a  particular  month  the  user  wishes  to  modify  his/her  schedule 
(without  changing  the  regular  schedule  that  still  continues  to 
apply),  this  is  done  by  making  a  modification  to  the  DS27  data  for 
that  particular  month  (in  Function  F4B).  If  the  user's  regular 
availability/preferred  time  use  schedule  actually  be  changed,  this  is 
shown  the  adding  a  new  set  of  DS26  data  with  the  new  regular  schedule 
and  a  new  date  that  this  schedule  is  applicable. 

Function  F4C  make  be  considered  to  be  a  subroutine  in  that  it  is  a 
processing  step  used  in  several  functions  to  prepare  the  OHMIS  data 
base  for  those  functions.  The  Function  F4L  subroutine  is  executed  in 
tnree  types  of  circumstances: 
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Periodical ly.  Once  every  month,  the  QHMIS  program 
generates  the  OS27  data  sets  for  the  next  two  months  in 
advance  for  all  performers  of  tasks  in  the  0HM1S  system  who 
have  DS26  data  covering  any  portion  of  the  time  in  those  two 
months.  This  process  sets  up  blank  monthly  schedule  data 
(DS27)  to  be  used  routinely  by  the  QHMIS  scheduling  function 
(Function  F4A  and  Step  F4B-7)  to  schedule  tasks  without  any 
further  preparation  for  those  tasks  scheduled  in  time  slots 
for  up  to  two  months  from  the  present  date.  This  use  of 
Function  F4C  is  initiated  in  Step  F1A-3  when,  once  a  month 
on  the  day  designated  for  doing  this  Function,  the  program 
logic  "sends"  (in  a  GO  TO  processing  substep)  the  OHMIS 
program  to  the  Function  F4C  subroutine  to  generate  the  new 
DS27  data  set.  The  program  "returns"  to  the  Step  F1A-3  when 
this  subroutine  is  completed. 

As  needed  for  scheduling.  Even  though  the  program  auto¬ 
matically  ensures  that  at  least  two  months  of  monthly 
scheduling  data  are  available,  it  may  occur  in  Function  F4A 
and  Step  F48-7  that  there  is  a  need  for  extra  months  of 
monthly  scheduled  data  in  order  to  schedule  a  particular 
task.  In  this  instance,  the  scheduling  program  identifies 
the  particular  individual  needing  extra  DS27  data  in  the 
year  and  month  for  which  this  data  is  needed.  The  program 
is  then  "sent"  (in  a  GO  TO  processing  substep)  to  the 
Function  F4C  subroutine,  't  "rtturns"  to  the  original 
scheduling  function,  wht-i  f  e  Function  F4C  has  completed  the 
generation  of  the  "blank"  „ >27  data  needed  for  the  schedul¬ 
ing  of  the  task  in  that  scheduling  function. 

Upon  the  request  of  the  user  (Menu  Selection  7.3.7).  It 
may  occur  that  the  user  will  wish  to  generate  a  blank  set  of 
monthly  schedule  data  (DS27)  for  a  particular  month.  This 
might  be  the  case,  for  example,  when  it  is  known  for  several 
months  in  advance  that  the  user’s  scheduling  availability 
will  be  temporarily  altered  ( i . e . ,  be  different  from  the 
regular  schedule  which  the  user  wishes  to  leave  unchanged), 
such  as  during  a  holiday  season.  The  user  may  wish  to 
generate  a  blank  set  of  0S27  data  so  that  changes  in  the 
availability  and  preferred  time  use  can  be  made  to  this  data 
as  soon  as  the  need  for  these  changes  is  known.  This  avoids 
having  the  OHMIS  program  Function  F4C  automatical ly  generat¬ 
ing  a  set  of  DS27  data  and  beginning  to  schedule  tasks  on 
that  DS27  data  with  the  regu) ar  schedule  availability/ 
preferred  time  use  data  on  it. 
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There  is  only  one  Step  in  Function  4C.  The  purpose  of  this  Step  has 

been  described  under  the  description  of  Function  F4C. 

PREVIOUS  STEP:  See  Rl  below. 

INPUTS  (S  =  Selection;  Q  =  Query  (not  stored);  E  =  Entry  (stored); 

R  =  Retrieval ) : 

Menu  Selection  and  Input  Sequence:  (Note.  This  Menu  Selec¬ 
tion  and  Input  Sequence  is  only  one  of  the  several  ways  that  the 
program  may  reach  Step  F4C-1;  it  is  the  only  way  in  which  the 
user  may  direct  the  program  to  this  step.) 

SI:  7  (scheduling  data) 

S2:  3  (monthly  schedule  data) 

S3:  7  (generate  a  "blank"  set  of  monthly  schedule  data) 

Ql:  Employee  identifier  (ID4)  of  the  person  for  whom  the 

monthly  schedule  data  is  to  be  generated.  Query  is 
in  P35. 

Q2:  OHMIS  service  area  identifier  ( I  DIO )  of  the  employee 

identified  in  Ql.  Query  is  in  P36. 

Q3:  Year  for  which  the  monthly  schedule  data  is  to  be 

generated.  Query  is  in  P37. 

Q4:  Month  for  which  the  monthly  schedule  data  is  to  be 

generated.  Query  is  in  P38. 

Data  Retrievals: 


Rl:  Flag  indicating  the  point  in  the  OHMIS  functional 

data  flows  from  which  the  program  prescribed  the  GO 
TO  PI  of  Step  F4C-1 

R2:  Processing  substep  to  which  the  program  is  to 

"return"  after  completing  Step  F4C.  This  information 
is  retained  at  the  time  that  the  Rl  flag  is 
generated . 

K 3:  Information  on  a  particular  set  of  DS27  data  that  is 

to  be  generated.  This  information  includes  the 
employee  identifier  (ID4),  year  and  month  and  OHMIS 
service  area  identifier  (IU10)  for  the  DS27  data  that 
is  to  be  generated.  This  information  is  retained  at 
the  time  that  tne  Rl  flag  is  generated. 

(NOTE:  Tne  Rl,  R2,  and  R3  values  are: 
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R1  =  P36  of  Step  F1A-3;  R2  =  P37;  R3  =  not  specified, 
the  program  determines. 

R1  =  P444  of  Step  F4A-3;  R2  =  P38;  R3  =  P445 

R1  =  P446  of  Step  F4A-3;  R2  =  P449;  R3  =  P445. 

R1/R2/R3  =  processing  substeps  equivalent  to  Step 
F4A-3  in  Steps  F4A-4,  F4A-5,  and  F4A-7. 

R1  =  P42  of  Step  F4B-7 ;  R2  =  P45;  R3  =  P43 

R1  =  PI 83  of  Step  F4B-7 ;  R2  =  P186;  R3  =  P184. 

R1  =  Menu  Selection  Sequence  7.3.7;  R2  =  the 

appropriate  type  of  Menu  ‘O'  (First  Level  Menu)  as 
determined  from  the  CT1  from  R5;  R3  =  Q1  through  Q4.) 

R4:  0HM1S  service  area  identifier  (IDlu)  from  P5  of  Step 

F1A-2 

R5:  OHMIS  user  type  (CT1)  from  P2  of  Step  F1A-2 

K6:  A  calendar  with  the  number  of  days  in  a  month  for 

each  of  the  months  of  a  year.  This  includes  the 
number  of  days  in  February  for  different  years  (for 
leap  years  and  non-leap  years).  This  calendar  also 
includes  the  day  of  the  week  (Monday  through  Sunday) 
for  each  day  of  the  year.  This  calendar  is  generated 
once  at  the  initiation  of  OHMIS  and  used  thereafter 
with  updates  each  year. 

R7:  Current  date 

R8:  The  once  a  month  date  on  which  the  new  DS27  data  is 

generated.  This  date  is  determined  once  at  the 
initiation  of  OHMIS. 

R9:  Next  avai lable  monthly  schedule  identifier  (ID27) 

0S9:  Current  user/position  identity  and  cdd;\-a  J  a  ^  ^ 

DS26:  Regular  weekly  schedule  availability  data 

0L34:  List  of  qualified  employee  identifiers  (ID4)  by  task 
type  (CT8)  and  by  OHMIS  service  area  ( I D 10 ) 

OL4J:  Libt  or  weekly  schedule  identifiers  (1028)  by 

employee  loentitier  (104)  anc  onMIS  service  area 

' : :  1 1  o ) 


STEP  F4C-1 


DL41:  List  of  the  monthly  schedule  identifiers  (102?)  for 
an  OHMIS  service  area  ( I D 10 )  with  the  corresponding 
year  and  month  covered  by  the  monthly  schedule  data 
(DS27)  identified  by  the  ID27  and  the  employee 
identifier  ( ID4)  of  the  employee  performing  the  task 
scheduled  on  this  DS27  data. 

PROCESSING  (P  =  Processing  Substep;  FN  =  For  Next  (program  logic 
loop)): 

PI:  Start  a  list,  called  the  PI  list.  This  list  will  consist 

of  the  information  about  the  characteristics  of  the  DS27 
data  that  is  to  be  generated.  Each  entry  on  the  PI  list 
will  consist  of  four  data  elements: 

(1)  Employee  identifier  (ID4)  of  the  employee  for  whom 
DS27  data  to  be  generated  is  a  monthly  schedule 

(2)  OHMIS  service  area  identifier  ( I D 10 )  for  the  above 
employee 

(3)  Year  of  the  monthly  schedule  data  (0S27)  to  be 
generated 

(4)  Month  of  the  monthly  schedule  data  (DS27)  to  be 
generated 

P2:  What  is  the  Rl  flag?  P36  of  Step  F1A-3  =  P3;  Menu 

Selection  Sequence  7.3.7  =  P35;  all  other  Rl  flags  =  P52 

P3:  Identify  the  year  that  is  part  of  the  R8  date. 

P4:  Identify  the  month  that  is  part  of  the  R8  month. 

P5:  Is  the  month  from  P4  a  '12'?  Yes  =  P8;  No  =  P6 

P6:  Generate  the  value  that  is  equal  to  the  value  in  P4,  plus 

T  . 

P 7 :  GO  TO  P10. 

P8:  Either  store  the  value  'l1  of  the  value  generated  in  P6, 

if  P6  was  executed. 

P9:  Derive  the  value  that  is  equal  to  the  value  in  P3  plus 

1 1’ . 

PIO:  Either  store  tne  value  that  is  equal  to  the  value 

identified  in  P3  or  is  equal  to  the  value  derived  in  P9, 
if  P9  was  exec  *'ed. 


P 11 : 


Start  a  list,  called  the  Pll  list.  This  will  be  a  list  of 
employee  identifiers  (104/. 
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FNl:  FOR  each  entry  on  the  DL34  list: 

P12:  Is  the  entry  for  this  iteration  of  FNl  for  the  OHM  I S 

service  area  ( I  DIO )  from  R4?  Yes  =  P13;  No  =  Pi 5  (next 
FNl) 

P13:  Identify  the  employee  identifier  (ID4)  on  the  entry  for 

this  iteration  of  FNl.  Is  this  104  on  the  Pll  list?  Yes 
=  P15  (next  FNl);  No  =  P14 

P14:  Put  the  ID4  identified  in  P13  on  the  Pll  list. 

P15:  NEXT  FNl;  end  of  FNl,  GO  TO  P16. 

P16:  Are  there  any  entries  on  the  Pll  list?  Yes  =  P 18 ;  No  = 

P 1 7 

P 1 7 :  Erase  the  Rl  flag.  GO  TO  (return)  to  the  point  given  in 

R2. 

P 18 :  Start  a  list,  called  the  P18  list.  This  list  will  be  in 

the  same  format  as  the  Pi  list. 

FN2:  FOR  each  entry  (employee  identifier  ( I 04 ) )  on  the  Pll 

list: 

P19:  Using  the  0L41  list,  determine  if  there  is  an  entry 

(monthly  schedule  identifier  (ID27))  or  -i.e  DL41  list  for 
the  ID4  for  this  iteration  of  FN2,  thi  <  IS  service  area 
identifier  ( I DIO )  from  R4,  the  year  fre  r3  and  the  month 
from  P4.  Yes  =  P21;  No  =  P20 

P20:  Add  an  entry  to  the  P18  list.  Put  the  ID4  for  this 

iteration  of  FN2  of  the  I DIO  from  R4,  the  year  from  P3, 
and  the  month  fro.  P4  onto  the  P18  list  entry. 

P21:  Using  the  0121  list,  determine  if  there  is  an  entry  (ID27) 

on  the  0L41  list  for  the  ID4  for  this  iteration  of  FN2, 
the  1010  from  R4,  the  year  from  PlO,  and  the  month  from 
P8.  Yes  =  P23  (next  FN2) ;  No  =  P22 

P22:  Add  an  entry  to  the  P18  list.  Put  the  104  for  this 

iteration  of  FN2,  the  I DIO  from  R4,  the  year  from  PlO,  and 

the  month  from  P8  onto  the  P18  list  entry. 

P23:  NEXT  FN2 ;  end  of  FN2,  GO  TO  P24. 

P24:  Are  there  any  entries  on  the  P18  list?  Yes  =  FN3  (P25); 

No  =  P17 

FN3:  FOR  each  entry  on  the  P18  list: 
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P25:  Identify  the  employee  identifier  (ID4)  that  is  data 

element  (1)  on  the  P18  list  entry  for  this  iteration  of 
FN3. 

P26:  Review  the  DL40  list  and  determine  if  there  are  any 

entries  (weekly  schedule  identifiers  ( I D28 ) )  on  the  DL40 
list  for  the  ID4  identified  in  P25  and  the  ID1Q  from  R4. 
Yes  =  P27;  No  =  P36  (next  FN3) 

P27:  Put  the  entries  (ID28s)  on  the  DL40  list  for  the  ID4  from 

P25  and  the  1010  from  R4  onto  a  temporary  list,  called  the 
P27  list. 

FN3.1:  FOR  each  entry  (ID 28)  on  the  P27  list: 

P28:  Locate  the  0S26  data  corresponding  to  the  ID28  for  this 

iteration  of  FN3.1. 

P29:  Identify  the  begin  and  end  dates  on  the  set  of  DS26  data 

located  in  P28.  (Note:  a  blank  end  date  indicates  that 
there  is  no  end  date  for  the  DS26  data,  i.e.,  that  it 
applies  indefinitely;  a  blank  end  date  should  be  treated 
as  though  the  end  date  were  any  date  later  than  the  begin 
date. ) 

P30:  Is  the  year  and  month  that  are  elements  (3)  and  (4)  on  the 

P18  list  entry  for  this  iteration  of  FN3  covered  by  the 
DS26  data  from  P28,  i.e.,  do  the  begin  and  end  dates 
identified  in  P29  cover  the  range  of  time  that  includes 
any  part  of  the  year/month  given  in  data  elements  (3)  and 
(4)  on  the  P18  list  entry  for  this  iteration  of  FN3?  Yes 
=  P32;  No  =  P31 

P31:  NEXT  FN3.1;  end  of  FN3.1,  GO  TO  P33. 

P32:  Copy  the  P18  list  entries  for  this  iteration  of  FNl  onto 

the  PI  list. 

P 3 3 :  NEXT  FN3;  end  of  FN3 ,  GO  TO  P34. 

P34:  Are  there  any  entries  on  the  PI  list?  Yes  =  FN5  (P53);  No 

=  P17 

P 35 :  (From  P2):  Ask  the  user  for  Q1  (employee  identifier  (ID4) 

of  the  person  for  whom  the  user  would  like  to  generate 
DS27  data). 

P36:  Ask  the  user  for  Q2  (OHMIS  service  area  identifier  ( I D 10 ) 

for  the  person  identified  in  P35). 

P37:  Ask  the  user  for  i|3  (y-ar  for  which  the  user  would  like 

0327  data  to  be  generated). 
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P38:  Ask  the  user  for  Q4  (month  for  which  the  user  would  like 

DS27  data  to  be  generated). 

P39:  Determine  whether  there  is  an  entry  on  the  DL41  list  for 

the  ID4,  ID10,  year  and  month  entered  in  P35  through  P38. 
Yes  =  P 40 ;  No  =  P42 

P40:  Tell  the  user  that  there  already  exists  a  set  of  DS27  data 

with  the  specifications  given  by  the  user. 

P41:  Ask  the  user  if  the  user  would  like  to  quit  or  make 

another  request  for  DS27  data  to  be  generated.  Quit  = 

P34;  another  request  =  P3b 

P42:  Review  the  0L40  list  and  determine  if  there  are  any 

entries  (weekly  schedule  identifiers  ( DL28 ) )  on  the  0140 
list  for  the  104  entered  in  P35  and  the  ID10  entered  in 
P36.  Yes  =  P45 ;  No  =  P43 

P43:  Tell  the  user  that  it  is  not  possible  to  generate  a  new 

set  of  DS27  data  for  the  person  and  time  specified  by  the 
user,  because  there  is  no  regular  weekly  schedule 
availability  data  (DS27)  for  the  person  specified  and  time 
specified. 

P44:  GO  TO  P41 

P45:  Put  the  entries  (ID28s)  which  are  the  DL40  list  and  cover 

the  I  DIO  from  P35  and  the  ID10  from  P36  onto  a  temporary 
list,  called  the  P45  list. 

FN4:  FOR  each  entry  (ID28)  on  the  P45  list: 

P46:  Locate  the  DS26  data  corresponding  to  the  1028  for  this 

iteration  of  FN4. 

P47:  Identify  the  begin  and  end  dates  on  the  set  of  DS26  data 

located  in  P46. 

P48:  Is  the  year  from  P37  and  the  month  from  P38  covered  by  the 

0S26  data  located  n  P46,  i.e.,  do  the  begin  and  end  dates 
identified  in  P47  cover  the  range  of  time  that  includes 
any  part  of  the  year/month  identified  in  P37  and  P38?  Yes 
=  P50;  No  =  P49 

P49:  NEXT  FN4 ;  end  of  FN4,  GO  TO  Pi 7. 

P50 :  Generate  an  entry  onto  the  PI  list.  This  entry  consists 

of  the  values  entered  in  P35  through  P38. 

Pbl:  GO  TO  FN5  (P53). 
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P52:  (From  P2):  Put  the  4  values  from  R3  onto  the  Pi  list. 

FN5:  FOR  each  entry  on  the  PI  list: 

P53:  Review  the  0L40  list  and  identify  all  entries  (week 

schedule  identifiers  ( ID28s ) )  for  the  104  and  the  I DIO 
that  are  data  elements  (1)  and  (2)  of  the  PI  list  entry 
for  this  iteration  of  FN5.  Put  the  0L40  list  entry  (1028) 
on  a  temporary  list,  called  the  P53  list. 

P54:  Generate  a  list,  called  the  P54  list.  Each  entry  on  this 

list  will  consist  of  3  data  elements: 

(1)  A  regular  weekly  scheduled  identifier  (ID28) 

(2)  The  begin  date  from  the  0S26  data  corresponding  to 
the  ID28  from  data  element  (1) 

(3)  The  end  date  for  the  ID28  from  data  element  (1) 

FN5.1:  FOR  each  entry  (1028)  on  the  P53  list: 

P55:  Locate  the  DS26  data  corresponding  to  the  ID28  for  this 

iteration  of  FN5.1. 

P56:  Identify  the  begin  and  end  dates  of  the  DS26  data  from 

P55.  Do  these  begin  and  end  dates  cover  any  part  of  the 
year  and  month  shown  in  data  elements  (3)  and  (4)  of  the 
PI  list  entry  for  this  iteration  of  FN5?  Yes  =  P57;  No  = 
P58  (next  FN5.1) 

P57:  Generate  an  entry  for  the  P54  list.  Put  the  ID28  for  this 

iteration  of  FN5.1  as  data  element  (1)  and  the  begin  and 
end  dates  identified  in  P56  as  data  elements  (2)  and  (3). 

P58:  NEXT  FN5.1;  end  of  FN5.1,  GO  TO  P59. 

P59:  Begin  to  generate  a  set  of  DS27  data.  Assign  the  ID27 

from  R9;  the  I DIO  from  data  element  (2)  of  the  PI  list 
entry  for  this  iteration  of  FN5;  the  year  and  month  from 
data  elements  (3)  and  (4)  of  the  PI  list  entry  for  this 
iteration  of  FN5;  and,  the  employee  identifier  (ID4)  from 
data  element  (1)  of  the  PI  list  entry  for  this  iteration 
of  FN5.  Obtain  the  OHMIS  user/position  identifier 
(ID13/ID14)  for  the  ID4  that  is  in  data  element  (1)  of  the 
PI  list  entry  for  this  iteration  of  FN5  from  the  DS9  data 
set  corresponding  to  this  ID4.  The  format  of  the  DS27 
data  set  should  be  to  have  96  time  slots  (one  for  each 
quarter  of  an  hour  period)  for  each  of  the  31  days  of  a 
month.  Assign  the  numbers  (1-31)  to  each  of  the  days  of 
the  month  and  the  time  slot  numbers  (1-96)  to  each  of  the 
time  slots  for  each  of  the  31  days  of  a  month.  Using  the 
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R6  data,  determine  how  many  days  of  the  month  there  are 
for  the  month  {and  year,  if  necessary)  given  in  data 
element  (4)  (and  data  element  (3))  of  the  PI  list  entry 
for  this  iteration  of  FN5.  If  there  are  less  than  31  days 
in  the  month,  fill  in  the  additional  days  as  follows:  (1) 
Answer  the  question  on  the  newly  generated  DS27  data  for 
the  day  about  whether  there  is  any  part  of  the  entire 
day  that  is  available  for  scheduling  as  'No1;  (2)  Answer 
the  question  for  each  of  the  96  time  slots  under  each  of 
these  additional  days  about  whether  the  time  slot  is 
available  for  scheduling  with  the  answer  'No'.  Also  using 
the  R6  list,  fill  in  the  day  of  the  week  (1-7)  for  each  of 
the  days  included  in  the  month. 

FN5.2:  FOR  each  of  the  days  of  the  month  (1-31)  on  the  DS27 
data  generated  in  P59: 

P60:  Is  the  entire  ciay  shown  on  the  DS27  data  as  not 

available  for  scheduling  (i.e.,  is  this  day  not  really  one 
of  the  days  of  this  month)?  Yes  =  P79  (next  FN5);  No  = 

P61 

P61:  Is  there  an  entry  on  the  P54  list  with  a  begin  and  end 

date  that  covers  the  year  and  month  shown  in  data  element 
(3)  and  (4)  of  the  PI  list  entry  for  this  iteration  of  FN5 
and  the  date  of  the  month  for  this  iteration  of  FN5.1? 

Yes  =  P64;  No  =  P62 

P62:  Fill  in  the  answer  on  the  DS27  data  generated  in  P59  for 

the  day  of  the  month  for  this  iteration  of  FN2  for  the 
question  about  whether  there  is  any  scheduling  time 
available  for  the  entire  day,  with  the  answer  'No'. 

Also  fill  in  the  question  about  whether  the  time  slot  is 
available  for  scheduling  on  each  of  the  96  time  slots  for 
the  day  of  the  month  for  this  iteration  of  FN5.2  with  the 
answer  1  No' . 

P63:  GO  TO  P78  (next  FN5.2). 

P64:  Identify  the  P54  list  entry  with  the  begin  and  end  dates 

covering  this  iteration  of  FN5.2,  i.e.,  this  year,  month 
and  day  of  the  month. 

P65:  Locate  the  0526  data  corresponding  to  the  1028  in  data 

element  (1)  on  the  P54  list  entry  located  in  P64. 

P66:  Identify  the  day  of  the  week  that  corresponds  to  the  day 

of  the  month  for  this  iteration  of  FN5.2.  (This  is  shown 
on  the  0527  data  for  this  day.) 

P67:  Locate  the  day  of  the  week  identified  in  P66  on  the  0S26 

data  located  in  P65. 
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P68:  Is  the  answer  on  the  DS26  data  located  in  P65  for  the  day 

of  the  week  located  in  P67  about  whether  there  are  any 
time  slots  on  this  entire  day  available  for  scheduling  a 
'Yes'  or  a  'No'?  Yes  =  FN5.2.1  (P69);  No  =  P62 

FN5.2.1:  FOR  each  time  slot  (1-96)  on  the  DS27  data  generated 
in  P59  for  the  day  of  the  month  for  this  iteration  of 
FN5.2: 

P69:  Locate  the  time  slot  for  this  iteration  of  FN5.2.1  on  the 

DS27  data  from  P59  for  the  day  of  the  week  in  this 
iteration  of  FN5.2. 

p 70 :  Locate  the  time  slot  for  this  iteration  of  FN5.2.1  on  the 
DS26  data  from  P65  for  the  day  of  the  week  located  in  P67. 

p 71 :  Does  the  0S26  data  time  slot  located  in  P7(J  snow  the  time 

slot  for  this  iteration  of  FN5.2.1  to  be  available  for 
scheduling?  Yes  =  P 74 ;  No  =  P72 

P 72 :  Enter  a  ’No’  on  the  DS27  data  time  slot  located  in  P69  for 

the  question  as  to  whether  this  time  slot  is  available  for 
scheduling. 

P 7 3 :  GO  TO  P77  (next  FN5.2.1). 

P74:  Enter  a  ’Yes’  on  the  DS27  data  time  slot  located  in  P69 

for  the  question  as  to  whether  this  time  slot  is  available 
for  scheduling. 

P 75 :  Identify  the  preferred  time  use  code  (CT11)  on  the  0S26 

data  time  slot  located  in  P70. 

P 76 :  Enter  the  CT11  identified  in  P75  onto  the  appropriate 

field  of  the  DS27  data  time  slot  located  in  P69. 

P 77:  NEXT  FN5.2.1;  end  of  FN5.2.1,  GO  TO  P78. 

P78:  NEXT  FN5.2;  end  of  FN5.2,  GO  TO  P79. 

P 7 9 :  NEXT  FN5 ;  end  of  FN5 ,  GO  TO  P17. 

OUTPUTS  AND  GENERATION  OF  DATA  SETS: 

DS27:  Monthly  schedule  data  (availability  and  use) 


VII.  RECOMMENDED  SYSTEM  DESIGN  -  PART  3 


System  Specifications  and  Features 


7.1  GENERAL  FEATURES 

OHMIS  is  essentially  a  DBMS  operated  in  concert  with  VIABLE  with 
requisite  interfaces  with  the  supply,  military  and  civilian  personnel 
and  facility  disk-to-disk  data  outputs  of  VIABLE.  To  facilitate 
deployment,  OHMIS  is  a  modular  system  designed  around  the  individual 
needs  and  capabilities  of  the  three  primary  types  of  users:  the 
Occupational  Health  organization,  the  Industrial  Hygiene  organization 
and  the  “System  Administrator"  (USAEHA)  (FIGURE  1). 

While  specific  design  details  are  not  yet  possible  as  VIABLE  technical 
data  is  still  closely  held,  OHMIS  will  be  primarily  an  on-line  system. 
That  is,  the  processing  will  be  done  on  a  transaction  basis  from  each 
installation  using  the  hardware  associated  with  the  five  VIABLE 
regional  centers.  This  process  can  be  used  for  all  commands  except 
DARCOM,  which  is  not  scheduled  to  receive  VIABLE.  DARCOM  installa¬ 
tions  will  use  a  communications  modem  to  access  the  nearest  VIABLE 
regional  center.  Transactions  will  be  entered  from  the  user's  ter¬ 
minal,  edited  for  accuracy  and  then  used  to  update  the  data  base  and 
generate  requested  responses.  Where  they  exist,  the  Occupational 
Health  and  Industrial  Hygiene  units  of  each  installation  and  major 
commands  may: 

o  add  data 

o  change  some  existing  data 

o  delete  data 

o  examine  data 

These  actions  are  subject  to  the  control  procedures  established  by  the 
"System  Administrator."  The  control  procedures  limit  each  type  of 
user's  access  to  only  those  selected  data  elements  applicable  to  the 
user. 

OHMIS  is  designed  to  minimize  user  training  requirements  through  use 
of  formatted  menus.  When  the  user  selects  the  type  of  action  desired, 
a  formatted  screen  containing  output  data  or  outlining  the  appropriate 
input  data  elements  is  displayed.  When  the  user  is  updating  the  data 
base,  all  information  keyed  in  and  transmitted  is  edited  by  highlight¬ 
ing  errors  on  the  screen  so  that  the  user  is  afforded  the  opportunity 
to  correct  the  error (s).  After  any  errors  have  been  corrected,  the 
data  is  then  presented  to  the  user  for  final  review.  After  this 
review,  the  user  may  transmit  the  data.  At  this  point,  the  data  base 
is  updated  and  the  transaction  completed. 

Disk-to  disk-updating  capabilities  will  be  provided  within  VIABLE  to 
interface  OHMIS  with  supply,  personnel  and  facility  data  systems. 


7.2  SPECIFIC  PERFORMANCE  REQUIREMENTS 


OHMIS  shall  be  designed  so  as  to  provide  for: 

1.  Modular  installation,  increasing  both  in  the  number  of 
application  modules  supported  and  in  the  number  of  locations 
served. 

2.  Use  by  non-AOP  personnel,  primarily  by  CRT  input/output, 
with  local  hard  copy  output  as  an  option  for  each  user. 

3.  Immediate  verification  of  data  input. 

4.  Generation  of  standard  periodic  reports,  upon  request  or  at 
the  end  of  fixed  time  intervals,  which  accurately  represent 
the  contents  of  the  data  base. 

5.  Inquiry  and  report  writer  functions  by  which  non-ADP 
personnel  can  generate  special  reports. 

6.  Security  factors  to  protect  information  covered  by  privacy 
or  classified  data  considerations,  and  to  protect  the 
integrity  of  the  data  base. 

7.  OHMIS  system  monitoring,  to  give  information  on  system 
usage,  problems  and  effectiveness,  and  to  report  attempted 
improper  use. 

8.  Application  program  development  tools  to  facilitate  system 
maintenance  and  enhancements. 

9.  Backup  and  restart  capabilities. 

10.  Sufficient  flexibility  to  allow  creation  or  deletion  of 
fields  and  records  without  major  reorganization  of  the  data 
base  system,  and  to  provide  for  rapid  buildup  of  the  data 
base  during  the  OHMIS  growth  phase. 

7.2.1  Accuracy  and  Validity 

System  hardware  and  software  shall  detect  and  trap  errors.  Data  files 
shall  be  updated  on-line  at  the  time  of  entry.  Since  multiple  users 
may  access  the  same  file,  provision  must  be  made  for  file  locking  and 
unlocking. 

Editing  Checks:  The  following  are  the  major  features  of  the  editing 
specifications  that  should  be  included  in  the  OHMIS  design: 

1.  Input  data  will  be  checked  for  form  (e.g.,  alphabetic, 
numeric,  date,  Social  Security  number)  and  validated  for 
range  against  system  constants  and  tables  before  being 
selected. 

2.  In  some  modules,  selected  data  elements  will  require 
validation  against  existing  files. 


3.  Input  data  that  fails  the  checking  procedure  will  be 
immediately  identified  to  the  user  for  correction  (exception 
notification ) . 

4.  Input  data  will  be  entered  through  formatted  screens.  After 
the  editing  and  validation  process,  users  will  be  provided 
the  capability  to  "review"  entries  prior  to  final  trans¬ 
mission  of  input.  Review  capability  should  include  ability 
to  select  a  given  line  on  the  screen  for  modification  and 
preferably  a  single-line  editing  mode  for  simplicity  in 
correcting  an  error  on  a  line. 

5.  Opportunity  shall  be  provided  for  return  to  menu  without 
transmission  of  input. 

6.  Batch  processing  editing  shall  provide  for  errors 
(exceptions)  being  identified  on  an  output  listing. 

Missing  Data:  Specified  data  elements  may  have  the  value  of 
“unknown."  These  must  be  distinguished  from  "zero"  value. 

7.2.2  Response  Times 

OHMIS  data  processing  is  only  moderately  time-sensitive  in  that 
degradation  of  timing  will  result  primarily  in  wasted  personnel  time 
rather  than  in  complete  failure  to  meet  significant  mission 
requ irements . 

Input  Data  Management:  The  time  interval  between  the  Co  ,  letion  of 
transmission  of  a  screen  of  data  and  the  readiness  of  the  next  screen 
of  data  input  should  not  exceed  five  seconds.  Design  of  the  data 
input  checking  methods  should  provide  for  as  rapid  a  response  as 
feasible. 

On-Line  Requirements:  Occasional  off-line  periods  of  as  long  as  one 
hour  could  be  tolerated.  Ninety-eight  percent  on-line  performance 
would  satisfy  OHMIS  requirements  for  efficient  personnel  use. 

Standard  Report  Generation:  Standard  (periodic)  reports  should  be 
generated  with  a  turnaround  time  from  initiation  of  request  (or 
automatic  initiation,  e.g.,  at  the  end  of  a  time  period)  of  24  hours. 

Special  Report  Generation:  On-line  generation  of  reports  is 
required  for  specified  OHMIS  functions  and  should  be  accomplished  with 
a  turnaround  time  not  to  exceed  30  minutes. 

7.2.3  Storage  Requirements 

Due  to  undeveloped  coding  schemes  used  to  classify  much  of  OHMIS1 
data,  it  is  not  possible  to  exactly  assess  the  on-line  storage 
requirements  of  OHMIS  at  this  time.  However,  using  estimated  field 
lengths  for  undefined  data  elements  and  approximation  of  the  number  of 
occurrences  expected,  the  estimated  on-line  storage  requirements  for 
full  scale  OHMIS  operation  is  761  million  bytes  system-wide. 
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7.2.4  Expected  Growth 


The  expected  growth  for  0HM1S  is  a  factor  of  five  (5)  as  the  system 
will  maintain  five  years  of  data  on-line  for  analysis.  Accordingly, 
five  years  from  the  system  start-up,  the  on-line  storage  requirement 
will  be  3.8  billion  bytes.  Archive  requirements  will  grow  at  a  rate 
of  761  million  bytes  per  year  for  a  maximum  of  25  years  or  19  billion 
bytes  of  archive  off-line  storage  requirements . 

7.3  FAILURE  CONTINGENCIES 

7.3.1  Fail ure  Modes 

Failure  conditions  that  must  be  considered  include  failure  of  major 
hardware  or  an  operating  system,  telecommunications  failure,  and 
failure  of  an  application  program  (whether  arising  from  system  error 
or  a  program  "bug"). 

Hardware/Operatinq  System  Failure:  As  discussed  in  Section  7.4,  a 
major  network  rather  than  a  stand-alone  hardware  environment  is 
envisioned  for  OHMIS.  Accordingly,  it  may  be  assumed  that  failure  of 
major  hardware  or  an  operating  system  will  be  handled  by  the 
appropriate  network  managers  and  that  status  messages  will  appear  on 
local  terminals. 

Applications  Program  Failure:  Programs  must  be  designed  for  use  by 
nontechnical  terminal  operators  and  must  have  error  trapping  that 
allows  the  user  to  continue  or  return  to  a  menu.  As  indicated  under 
"restart"  in  Section  3.5.4,  the  user  must  be  able  to  determine 
unambiguously,  in  the  event  of  a  failure  during  transaction  pro¬ 
cessing,  which  data  items  have  been  accepted  and  which  have  not. 

Telecommunications  Failure:  It  may  be  assumed  that  failure  of  the 
telecommunications  functions  of  the  network  will  be  handled  by  network 
managers.  Failures  should  result  in  an  unambiguous  indication  to  the 
terminal  operator  that  the  system  is  not  operative.  Some  modules  of 
the  OHMIS  system  may  require  input  of  industrial  hygiene  data  in  the 
field  through  the  use  of  portable  printing  terminals  and  local  dial-up 
lines.  These  lines  may  introduce  considerable  noise  into  echo-back  or 
printout  and  provision  must  be  made  in  programming  for  an  option  to 
provide  a  confirmatory  printout  of  data  that  has  been  input. 

7.3.2  Backup  Requirements 

OHMIS  should  provide  the  capability  to  backup  to  tape  all  on-line 
files  used  to  support  functional  nodules.  Backup  shall  be  routine  and 
periodic,  or  on  demand.  Backup  tapes  shall  include  as  data  on  the 
tape  itself  positive  identification  information  regarding  date,  time 
and  files  copied.  OHMIS  shall  also  provide  the  capability  to  restore 
on-line  files  from  backup  tapes. 

OHMIS  shall  also  provide  the  capability  to  archive  to  machine-readable 
media  all  records,  removed  from  the  on-line  files  at  the  time  of  each 
purge  run.  The  date,  time  and  files  copied  must  be  included  in  the 
data  on  the  media. 
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To  cope  with  failure  resulting  in  data  loss  between  backups,  0HM1S 
must  provide  either  a  hard  copy  "audit  trail"  to  each  user  or  a  file 
maintenance  log  tape  that  car  be  used  to  regenerate  entries.  It  must 
be  possible  for  users  to  know  unambiguously  which  transactions  have 
been  recorded  by  OHMIS. 

Restart  Requirements:  OHMIS  must  provide  the  capability  for  cold 
start.  Restart  and  recovery  arising  from  system  failure  may  be 
assumed  to  be  controlled  by  the  network  managers.  OHMIS  must  provide 
that  the  transactions  processed  prior  to  or  during  system  failure  and 
restart  are  either  correctly  processed  with  appropriate  file  updates 
or  rejected,  and  the  user  must  know  unambiguously  at  which  point  in 
the  transaction  sequence  current  processing  stopped.  The  user  must  be 
able  to  restart  transaction  processing  at  this  point  or  at  the 
preceding  menu. 

Fallback  Requirements:  The  physical  location  of  OHMIS  on-line  files 
within  the  network  (see  Section  7.4)  should  be  such  as  to  allow 
continued  local  processing  of  as  many  modules  as  possible  in  the  event 
of  telecommunications  failure  between  local  Army  posts  and  regional 
data  centers.  Such  failure  would  preclude  access  to  interfaced  data 
systems . 

7.4  ENVIRONMENT 


7.4.1  Equipment  Environment 


OHMIS  comprises  a  network  of  fac i 1 i ty- level  user  processing  data  for 
local  use,  in  addition  to  one  or  more  central  offices  plus  interfaces 
to  numerous  other  systems.  The  central  offices  will  require  two-way 
on-line  data  communication  with  the  local  users.  Incremental  growth 
is  planned,  both  in  the  number  of  local  users  and  in  the  program  set 
used  by  each.  The  equipment  requirements  can  by  met  be  a  large  U.  S. 
Army-wide  data  processing  network  such  as  VIABLE,  incorporating 
distributed  data  processing  systems  linked  to  regional  data  centers 
through  telecommunications. 


Local  data  processing  centers  must  have  at  least  the  following 
capabilities  (either  provided  locally  or  via  the  network): 


a.  Processor.  The  CPU  must  have  sufficient  allocable  memory 
(minimum  256 K )  to  efficiently  run  any  data  base  management 
system  used. 


b.  Storage  Media.  Direct-access  requirements  at  each 

locality  will  be  a  function  of  the  number  of  employees  and 
facilities  served  by  that  locality,  typically  500  million 
characters. 


c.  Output  Devices.  Each  locality  will  require  as  a  minimum  a 
high-speed  printer  and  a  tape  drive.  Multiple  CRT  terminals 
with  graphics  and  editing  capabilities  will  be  required  as 
input-output  devices,  with  nearby  low-speed  printers 
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(typically  120  characters/sec)  with  graphics  and 
form-handling  capability.  Portable  printing  terminals  will 
also  be  required  for  field  input/output  of  data  via  local 
phone  lines.  Typically,  each  locality  will  require  three 
dedicated  CRT/printer  units  and  two  portable  printing  termi¬ 
nals.  The  remaining  element  can  be  shared. 

d.  Input  Devices.  Each  locality  will  require  as  a  minimum  a 
a  tape  drive  and  a  card  reader.  During  the  initial  data 
load-up  phase,  OCR  equipment  would  be  desirable. 

e.  Communications.  Within  each  locality,  communications 
facilities  must  allow  each  CRT  terminal  to  operate  at  a 
minimum  of  9600  bps,  and  each  printer  to  operate  at  its 
rated  speed. 

The  central  office  will  require  a  dedicated  tape  drive  and  RJE 
equipment,  a  high-speed  printer,  multiple  CRT  terminals  with  editing 
and  graphics  capability,  and  rrultiple  letter-quality  printers.  At 
least  one  CRT  terminal  must  be  equipped  to  utilize  the  program 
development  utilities  of  the  overall  system.  Access  to  a  shared  card 
reader,  card  punch,  additional  high-speed  printers,  OCR  equipment  and 
tape  drives  will  also  be  required. 

7.4.2  Support  Software  Environment 

The  operating  system  must  have  multitasking,  multithread  capabilities 
to  perform  the  following  functions: 

o  program  testing  and  development; 

o  interactive  transaction  processing; 

o  batch  and  on-lit  j  file  input,  inquiry,  and  update; 

o  monitoring  for  OHMIS  system; 

o  access  to  non-OHMiS  files; 

o  multilevel  security  for  access  and  update; 

o  restart  and  recovery  without  uncontrolled  lows  of 
transaction  data  and  without  file  damage; 

o  electronic  mail; 

o  downloading  of  program  updates  from  central  office  to 
local i ties ; 

o  data  base  management  with  relational  capabilities. 

The  operating  system  must  support  all  currently  valid  high-level 
languages,  including  as  a  minimum  Army  Standard  COBOL  and  ANSI  FORTRAN 
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7.4.3  Interfaces 


The  following  systems  have  been  identified  as  interface  requirements 
for  OHMIS,  with  the  indicated  access  requirements  (on-line  or  batch): 

a.  SAILS 

b.  SIDPERS 

c.  SCIPMIS 

d.  JUMPS 

e.  STARCIPS 

f.  IFS 


Batch  data  transfer  may  be  via  tape  or  telecommunications.  OHMIS  does 
not  directly  update  any  files  in  these  data  systems.  Any  data  errors 
or  discrepancies  noted  will  be  transmitted  to  the  appropriate  system 
manager  by  electronic  mail. 

7.4.4  Security  and  Privacy 

OhMIS  contains  patient-sensitive  data  which  is  subject  to  the 
provisions  of  the  Privacy  Act  of  1974,  resident  in  the  system  either 
by  input  from  an  OHMIS  module  or  by  transfer  via  an  interface  from 
another  system.  System  security  must  be  designed  to  limit  and  control 
access  to  the  entire  OHMIS  system,  limit  specified  functions  to 
authorized  users,  and  meet  requirements  of  interfaced  systems  from 
which  data  is  transferred.  (Some  data  elements,  e.g.,  supply  data, 
special  chemicals,  may  involve  classified  data.)  System  security 
should  be  table-driven. 
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